I did my best to reproduce your setup, but I got no crashes. One thing I'd like to ask is: I see some non-standard attributes in the pcache configuration. Can you tell whether there might occur some schema inconsistencies between the remote server and the proxy?
No, they're the same - the schema files are distributed via RPM and configured in slapd.conf with the same bit of configuration code.
Also, can you tell how often crashes occur, or any detail about the type of operation, the workload and so?
The machines I'm currently testing with are all in a student lab, running condor jobs when quiet, so a bit difficult to predict - I haven't seen any discernible pattern so far - I've seen crashes on busy machines and quiet ones.
For the core file we're looking at here, this machine had answered 9 queries in the second prior to the crash, but had been quiet for 3 minutes prior to that after it had removed stale entries from the cache. I can attach a portion of the slapd log if it would be useful.
As for how often the crashes occur, these 24 lab machines have been running 2.4.15 built with no optimisation since 27th Feb and have produced 18 core files in that time. Of these, approximately half have been assertion failures for free(p) in memory.c:152.
I've seen 3 cases of segfaults in pcache_filter_cmp, as mentioned in ITS#5756, but I'll submit non-optimised backtraces to that ticket, rather than confuse the issue here.
I also disabled slab allocation, so that true mallocs occur all times, and valgrind is not showing any memory issue.
The difficulty is in trying to reproduce this - my own desktop machine is running with the same setup and has never crashed, despite my best efforts.
Cheers Toby