RE: slurpd segfaults

["Mike Denka" <mdenk@whidbey.net>]

I sent the enclosed message to the list last Friday and haven't received
any responses.  It turns out that the problem (slurpd segfaulting)
appears to have been caused by malformed data in the slurpd.replog file.
So my question is twofold:

1) How do we suppose that the slurpd process screwed up the data in the
first place when it wrote the slurpd.replog file and what's to prevent
this from happening on a regular basis?

And

2) Why would slurpd even care if data close to the beginning of the
slurpd.replog file is malformed?  Why does slurpd read that file every
time it finds updates in the replog file created by slapd and goes to
replicate to the replica's? Furthermore, if slurpd has to read this file
every time it replicates, it must need data from it, so what is the
penalty for clearing out this file from time to time (as it grows to
unwieldy proportions or becomes malformed again)?

Thanks,

Mike



-----Original Message-----
From: owner-openldap-software@OpenLDAP.org
[mailto:owner-openldap-software@OpenLDAP.org] On Behalf Of Mike Denka
Sent: Friday, December 06, 2002 3:48 PM
To: openldap-software@OpenLDAP.org
Subject: slurpd segfaults


Slurpd might run a minute or an hour, but after some time, it segfaults.
The debug output just prior to the segfault always seems to be the same:

re-write on-disk replication log
Segmentation fault

I have two replicas running and while the master runs, the updates
proceed fine.  Until the segfault occurs.  I haven't seen the "re-write
on-disk replication log" message anywhere that it doesn't cause a
segfault.

Any ideas what might be causing this?

Thanks,

Mike