Full_Name: Ben Morrow Version: 2.4.39 and git head OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.140.232.115) I believe I have found a crashing bug in the syncprov overlay. If I start a refreshAndPersist search, wait for the persist phase to start and at least one change to be returned, and then cancel the search, slapd dies with SIGSEGV. (I don't know how many of these conditions are necessary. I suspect that cancelling any syncprov search will cause the same crash, but I haven't investigated that.) I also believe the following change to servers/slapd/overlays/syncprov.c:syncprov_ab_cleanup fixes the prlelem: slap_callback *sc = op->o_callback; op->o_callback = sc->sc_next; - syncprov_drop_psearch( op->o_callback->sc_private, 0 ); + syncprov_drop_psearch( sc->sc_private, 0 ); The crash I see actually occurs in libthr (FreeBSD's threading library), because drop_psearch passes its first argument to free_syncop which starts by trying to lock a mutex; but in fact the object being passed is not the right type at all, and where there is supposed to be a mutex there is instead a function pointer. Ben
ben@morrow.me.uk wrote: > Full_Name: Ben Morrow > Version: 2.4.39 and git head > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.140.232.115) > > > I believe I have found a crashing bug in the syncprov overlay. If I > start a refreshAndPersist search, wait for the persist phase to start > and at least one change to be returned, and then cancel the search, > slapd dies with SIGSEGV. (I don't know how many of these conditions are > necessary. I suspect that cancelling any syncprov search will cause the > same crash, but I haven't investigated that.) > > I also believe the following change to > servers/slapd/overlays/syncprov.c:syncprov_ab_cleanup fixes the prlelem: > > slap_callback *sc = op->o_callback; > op->o_callback = sc->sc_next; > - syncprov_drop_psearch( op->o_callback->sc_private, 0 ); > + syncprov_drop_psearch( sc->sc_private, 0 ); > > The crash I see actually occurs in libthr (FreeBSD's threading library), > because drop_psearch passes its first argument to free_syncop which > starts by trying to lock a mutex; but in fact the object being passed is > not the right type at all, and where there is supposed to be a mutex > there is instead a function pointer. Thanks, looks like you're right. Fixed in git master. > > Ben > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Open to Test moved from Incoming to Software Bugs
changed notes changed state Test to Release
fixed in master fixed in RE25 fixed in RE24
changed notes changed state Release to Closed