ben(a)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/
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
Full_Name: Quanah Gibson-Mount
Version: 2.4.39
OS: Linux 3.13
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.58.125)
After modifying olcListenerThreads for a running slapd, the process died and I
had to restart ldap. Going to see if cores were enabled.
graehl(a)gmail.com wrote:
> Full_Name: Jonathan Graehl
> Version: commit 8d346721a60684aeaa7b1e3b2111c972393bfad3
> OS: linux
> URL:
> Submission from: (NULL) (75.85.99.117)
>
>
> mdb_from_db Berkeley DB->LMDB import utility
Interesting, thanks for the submission.
> +Additionally,
> +.B mdb_from_db
> +may write in the
> +.B -T
> +plain text format understood by
> +.BR mdb_load (1)
> +which can only understand a single subdatabase at a time.
Not true. mdb_load can load multiple DBs from a single input file.
Also, I'm not sure if it's your mailer or ours, but this submission text is
riddled with corruptions.
> +
> B2B.SH OPTION0D0D
In general I don't think including this utility into LMDB is a good idea since
it has an obvious binary dependency on BerkeleyDB. In particular, with the
change of BerkeleyDB's license to AGPL it would not be possible for anyone to
distribute any binaries for this package.
Better to just use BDB db_dump piped into mdb_load.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
info-openldap(a)ch2o.info wrote:
> Full_Name: Mathieu CARBONNEAUX
> Version: 2.4.37
> OS: Centos 6.4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (86.73.162.197)
>
>
> hi,
>
> there any solution to support rfc2696 "Simple Paged Results Manipulation" in
> perl-backend ?
> actualy they respond err=12 (LDAP_UNAVAILABLE_CRITICAL_EXTENSION) without
> calling perl script...
The ITS is for bug reports, not usage questions.
Use the -technical mailing list for usage questions.
Closing this ITS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Full_Name: Mathieu CARBONNEAUX
Version: 2.4.37
OS: Centos 6.4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (86.73.162.197)
hi,
there any solution to support rfc2696 "Simple Paged Results Manipulation" in
perl-backend ?
actualy they respond err=12 (LDAP_UNAVAILABLE_CRITICAL_EXTENSION) without
calling perl script...
Best Regards,
Mathieu
ebackes(a)symas.com wrote:
> Full_Name: Emily Backes
> Version: RE24
> OS:
> URL:
> Submission from: (NULL) (50.113.67.84)
>
>
> Changing olcDbDirectory on a live server with overlays makes a mess; much like
> the recent ITS#7906, constraint has a problem with open/close management.
>
> constraint_close calls constraint_free( ap, 1 ) which wipes everything out, but
> the state is not restored when things are restarted. In particular, a second
> olcDbDirectory mod results in constraint_free being called again with garbage.
Should note this is related to ITS#7906. I guess we have no choice now but to
revisit all of the remaining overlays in RE24.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/