Thanks, Gavin. My GDB foo is not up to getting useful info out of your core dump, but I have placed one from one of our test rigs at
http://pastebin.siriusit.co.uk/slapd-2.4.8-nullpointer-bin-and-core.tar.gz
Note that this expects to be looked at with 64-bit GDB 6.7.1 from Debian Lenny/Sid (GDB 6.4.90 from Etch doesn't work).
Re your previous comments:
The engineer who put together the test case did look for bug reporting guidelines, but their location in the FAQ is, IMHO, non-obvious; perhaps one day I'll fix that. I reviewed and edited the report before sending it and I think it meets any reasonable person's definition of at least attempting to be helpful whilst not unduly verbose.
Posting to the wrong list was my fault and I apologise. The moderator was correct to reject the original message.
We know all kinds of weird stuff happens if you restart the crashed server(s) - that's how we come to be looking at this in the first place. We have, however, tried very hard to come up with a simple, confined case of this particular null pointer dereference, which is the first thing that goes wrong if you start from a clean sheet with empty databases each time and follow the recipe.
In the four environments we can easily construct (RHEL vs Debian, i386 vs amd64) the segfault of server1 happens immediately you submit any change via LDAP to server2.
Can anyone else reproduce this, or do we need to work on more examples?
Cheers
Duncan