[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#7928) Segfault when cancelling syncprov search
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#7928) Segfault when cancelling syncprov search
- From: hyc@symas.com
- Date: Fri, 29 Aug 2014 01:20:29 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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/