Well, it would look like to me then that this problem was introduced
between 2.2.6 and 2.2.11, and 2.1.25 and 2.1.29, since I have
not had any
problems on those earlier version, and I know changes were
made to slurpd
since then. Perhaps the out-of-order fix to slurpd impacted
it, I know
that was a major bug fix...
The diff's to slurpd from 2.1.25 to 2.1.29 are largely cosmetic, mostly in
comments and error message reporting. The out-of-order fix was a change to
how slapd generates the replog, not a code change in slurpd. Since the
slurpd code has not changed, and only the replog itself is different, one
would expect all of your replicas to behave identically since they're all
using the same replog.
Probably you need a debug/non-optimized build of slurpd to track this down
and get some good stack traces. If the stack traces aren't telling
anything useful, that tends to imply that the stack itself is trashed.
(The trace you provide in ITS#3123 is conspicuous in that it only goes
back as far as libthread, and doesn't tell anything about the calling
program.)