openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 07 Apr '09

07 Apr '09

> When a program aborts it will print an error message on stderr. It > would be useful to have that message. Long since disappeared for this case, I'm afraid. I'll try and get it in the future. > Can you please update to RE24, the 2.4.16 candidate, and see if the > behavior has changed? Also, can you please be sure to compile > without optimization (or with frame pointers intact; gcc > -fno-omit-frame-pointer); there seem to be a few functions missing > in these stack traces. > > Also grab the latest overlays/pcache.c (1.168). It probably won't > fix things, but it should make the crashes a little more obvious. OK, I've built 2.4.16 (which I see has the new pcache.c) with no optimisation (-O0 and -fno-omit-frame-pointer) and will put in place in our test lab. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by luca.scamoni＠sys-net.it 07 Apr '09

07 Apr '09

Howard Chu ha scritto: > > This trace is bogus, there's no call from slapd_daemon_destroy() to > epoll_wait() in the code. And you wouldn't have gotten to > slapd_daemon_destroy() unless you were shutting down. > > > This is also bogus; is this an optimized compile? It's always hard to > tell how much to trust the debugger here; if there are no further stack > frames then possibly the stack was overwritten. But if you compiled with > any type of optimization, and didn't use -fno-omit-frame-pointer, then > that may be all that's happening here. > I managed to find out how to reproduce the issue. Now it's deterministic and happens with openldap-2.4.16. The segfault can be caused by performing an ldapmodify on a specific entry replacing a binary attribute certificateRevocationList. I'm sending privately the backtrace analized with gdb and the slapd.conf file Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6048) All mailing list archives have stopped at March
by Kurt＠OpenLDAP.org 06 Apr '09

06 Apr '09

On Apr 6, 2009, at 2:27 PM, ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Just a quick ticket to mention that since the upgrade all the > mailing list > archives have stopped at March. This problem has been fixed. Unfortunately, there will be a hole in the archives unless someone happens to have a decent mbox archives for backfill (maybe one of the 3rd party mail archives have mbox archives available). -- Kurt

1 0

(ITS#6048) All mailing list archives have stopped at March
by ghenry＠OpenLDAP.org 06 Apr '09

06 Apr '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Just a quick ticket to mention that since the upgrade all the mailing list archives have stopped at March. Thanks.

1 0

Re: (ITS#6047) bdb cache seg. fault
by rein＠OpenLDAP.org 06 Apr '09

06 Apr '09

quanah(a)zimbra.com wrote: > --On Monday, April 06, 2009 6:15 PM +0000 rein(a)OpenLDAP.org wrote: >> I have had a couple of seg. faults in back-bdb cache.c during full resync >> of a consumer. The default bdb *cachesize configuration was being used >> (which was way too low now that cache limits are enforced more >> strictly..). Some info from two of the core files are listed below, the >> core files are available for further analyze. > > DB_CONFIG cachesize or slapd.conf cachesize? DB_CONFIG: set_cachesize 0 75497472 0 set_lk_max_locks 10000 set_lk_max_objects 5000 No *cachesize directives in slapd.conf. Rein

1 0

Re: (ITS#6047) bdb cache seg. fault
by quanah＠zimbra.com 06 Apr '09

06 Apr '09

--On Monday, April 06, 2009 6:15 PM +0000 rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: 2.4.16 > OS: linux > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > I have had a couple of seg. faults in back-bdb cache.c during full resync > of a consumer. The default bdb *cachesize configuration was being used > (which was way too low now that cache limits are enforced more > strictly..). Some info from two of the core files are listed below, the > core files are available for further analyze. DB_CONFIG cachesize or slapd.conf cachesize? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6047) bdb cache seg. fault
by rein＠OpenLDAP.org 06 Apr '09

06 Apr '09

Full_Name: Rein Tollevik Version: 2.4.16 OS: linux URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein I have had a couple of seg. faults in back-bdb cache.c during full resync of a consumer. The default bdb *cachesize configuration was being used (which was way too low now that cache limits are enforced more strictly..). Some info from two of the core files are listed below, the core files are available for further analyze. Rein Tollevik Basefarm AS Core 1: Program terminated with signal 11, Segmentation fault. #0 0x0000002a9677ac3c in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 (gdb) where #0 0x0000002a9677ac3c in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #1 0x0000002a9567eaa3 in ldap_pvt_thread_mutex_lock (mutex=0x38) at thr_posix.c:296 #2 0x00000000004be2ae in bdb_cache_delete_internal (cache=0x8e1970, e=0x2ac86a0b60, decr=0) at cache.c:1372 #3 0x00000000004beafb in bdb_cache_lru_purge (bdb=0x8e1910) at cache.c:776 #4 0x00000000004bf686 in bdb_cache_find_id (op=0x410006b0, tid=0xe82bd0, id=1, eip=<value optimized out>, flag=0, lock=0x40e7f4d0) at cache.c:1053 #5 0x00000000004c3563 in bdb_dn2entry (op=0x410006b0, tid=0xe82bd0, dn=<value optimized out>, e=0x40e7f500, matched=1, lock=0x40e7f4d0) at dn2entry.c:67 #6 0x00000000004ab5ac in bdb_search (op=0x410006b0, rs=0x40ffffb0) at search.c:374 #7 0x0000000000496b9a in overlay_op_walk (op=0x410006b0, rs=0x40ffffb0, which=<value optimized out>, oi=0x8e20a0, on=0x0) at backover.c:669 #8 0x00000000004975a6 in over_op_func (op=0x410006b0, rs=0x1, which=op_bind) at backover.c:721 #9 0x000000000049769e in over_op_search (op=0x38, rs=0x2ac86a0b60) at backover.c:743 #10 0x0000000000494728 in glue_sub_search (op=0x410006b0, rs=0x40ffffb0, b0=0x0, on=0x8e0a40) at backglue.c:342 #11 0x00000000004953b5 in glue_op_search (op=0x410006b0, rs=0x40ffffb0) at backglue.c:465 #12 0x0000000000496b47 in overlay_op_walk (op=0x410006b0, rs=0x40ffffb0, which=<value optimized out>, oi=0x8e5860, on=0x8d88e0) at backover.c:659 #13 0x00000000004975a6 in over_op_func (op=0x410006b0, rs=0x1, which=op_bind) at backover.c:721 #14 0x000000000049769e in over_op_search (op=0x38, rs=0x2ac86a0b60) at backover.c:743 #15 0x000000000048f3ba in syncrepl_entry (si=0x8e5520, op=0x410006b0, entry=0x9f74d8, modlist=0x41000458, syncstate=1, syncUUID=0x41000500, syncCSN=0x0) at syncrepl.c:2132 #16 0x00000000004925ff in do_syncrep2 (op=0x410006b0, si=0x8e5520) at syncrepl.c:892 #17 0x0000000000494166 in do_syncrepl (ctx=<value optimized out>, arg=0x8e52f0) at syncrepl.c:1361 #18 0x00000000004316d4 in connection_read_thread (ctx=0x41000e10, argv=<value optimized out>) at connection.c:1225 #19 0x0000002a9567e297 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:663 #20 0x0000002a96779137 in start_thread () from /lib64/tls/libpthread.so.0 #21 0x0000002a9694f543 in clone () from /lib64/tls/libc.so.6 #22 0x0000000000000000 in ?? () (gdb) frame 2 #2 0x00000000004be2ae in bdb_cache_delete_internal (cache=0x8e1970, e=0x2ac86a0b60, decr=0) at cache.c:1372 1372 bdb_cache_entryinfo_lock( e->bei_parent ); (gdb) print *e $1 = {bei_parent = 0x0, bei_id = 14820, bei_lockpad = 0, bei_state = 128, bei_finders = 0, bei_nrdn = {bv_len = 7, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 2, __m_count = 0, __m_owner = 0x10000186c, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0xabf230, bei_lruprev = 0x0} (gdb) frame 3 #3 0x00000000004beafb in bdb_cache_lru_purge (bdb=0x8e1910) at cache.c:776 776 bdb_cache_delete_internal( &bdb->bi_cache, elru, 0 ); (gdb) print eicount $2 = 0 (gdb) print eifree $3 = 10 Core 2: Program terminated with signal 11, Segmentation fault. #0 0x0000002a9677ac3c in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 (gdb) where #0 0x0000002a9677ac3c in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #1 0x0000002a9567eaa3 in ldap_pvt_thread_mutex_lock (mutex=0x38) at thr_posix.c:296 #2 0x00000000004be2ae in bdb_cache_delete_internal (cache=0x8e1970, e=0x2acdee8af0, decr=0) at cache.c:1372 #3 0x00000000004beafb in bdb_cache_lru_purge (bdb=0x8e1910) at cache.c:776 #4 0x00000000004bf686 in bdb_cache_find_id (op=0x418003a0, tid=0xacf790, id=10150, eip=<value optimized out>, flag=0, lock=0x4167fb90) at cache.c:1053 #5 0x00000000004acde5 in bdb_search (op=0x418003a0, rs=0x41800330) at search.c:706 #6 0x0000000000496b9a in overlay_op_walk (op=0x418003a0, rs=0x41800330, which=<value optimized out>, oi=0x8e20a0, on=0x0) at backover.c:669 #7 0x00000000004975a6 in over_op_func (op=0x418003a0, rs=0x1, which=op_bind) at backover.c:721 #8 0x000000000049769e in over_op_search (op=0x38, rs=0x2acdee8af0) at backover.c:743 #9 0x0000000000494728 in glue_sub_search (op=0x418003a0, rs=0x41800330, b0=0x0, on=0x8e0a40) at backglue.c:342 #10 0x00000000004953b5 in glue_op_search (op=0x418003a0, rs=0x41800330) at backglue.c:465 #11 0x0000000000496b47 in overlay_op_walk (op=0x418003a0, rs=0x41800330, which=<value optimized out>, oi=0x8e5860, on=0x8d88e0) at backover.c:659 #12 0x00000000004975a6 in over_op_func (op=0x418003a0, rs=0x1, which=op_bind) at backover.c:721 #13 0x000000000049769e in over_op_search (op=0x38, rs=0x2acdee8af0) at backover.c:743 #14 0x0000002a9a71c5b9 in syncprov_findcsn (op=0xdc83f0, mode=FIND_PRESENT) at syncprov.c:707 #15 0x0000002a9a71d806 in syncprov_op_search (op=0xdc83f0, rs=0x41801cc0) at syncprov.c:2484 #16 0x0000000000496b47 in overlay_op_walk (op=0xdc83f0, rs=0x41801cc0, which=<value optimized out>, oi=0x8e5860, on=0x8d8dd0) at backover.c:659 #17 0x00000000004975a6 in over_op_func (op=0xdc83f0, rs=0x1, which=op_bind) at backover.c:721 #18 0x000000000049769e in over_op_search (op=0x38, rs=0x2acdee8af0) at backover.c:743 #19 0x000000000043292a in fe_op_search (op=0xdc83f0, rs=0x41801cc0) at search.c:366 #20 0x000000000043336c in do_search (op=0xdc83f0, rs=0x41801cc0) at search.c:217 #21 0x0000000000430775 in connection_operation (ctx=0x41801e10, arg_v=<value optimized out>) at connection.c:1097 #22 0x00000000004316c8 in connection_read_thread (ctx=0x41801e10, argv=<value optimized out>) at connection.c:1223 #23 0x0000002a9567e297 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:663 #24 0x0000002a96779137 in start_thread () from /lib64/tls/libpthread.so.0 #25 0x0000002a9694f543 in clone () from /lib64/tls/libc.so.6 #26 0x0000000000000000 in ?? () (gdb) frame 2 #2 0x00000000004be2ae in bdb_cache_delete_internal (cache=0x8e1970, e=0x2acdee8af0, decr=0) at cache.c:1372 1372 bdb_cache_entryinfo_lock( e->bei_parent ); (gdb) print *e $1 = {bei_parent = 0xa775e0, bei_id = 10151, bei_lockpad = 0, bei_state = 128, bei_finders = 0, bei_nrdn = {bv_len = 11, bv_val = 0x2acec4b630 "dc=ud-www01"}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x100001789, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0xd671c0, bei_lruprev = 0xd671c0}

1 0

Re: (ITS#6046) BDB Support -no member named 'lk_handle'
by quanah＠zimbra.com 06 Apr '09

06 Apr '09

--On Monday, April 06, 2009 10:30 AM +0000 alex.ist(a)wirklich.net wrote: > Full_Name: Alexander > Version: 2.4.11 > OS: Fedora 10 > URL: > Submission from: (NULL) (213.150.1.77) > > > Hello, > I would like to install OpenLDAP 2.4.11 on Fedora FC10. > It seems that it comes with BDB Berkeley DB 4.7.25 > I experience an error during make that seems to be related with a wrong > version. > is this combination supported? > should I install an older version of the database? > I used the last stable version of OpenLDAP. BDB 4.7 support only exists in 2.4.12 or later. Please use OpenLDAP 2.4.16 instead of 2.4.11, as there have literally been hundreds of fixes since 2.4.11, and it is magnitudes more stable than 2.4.11. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6046) BDB Support -no member named 'lk_handle'
by alex.ist＠wirklich.net 06 Apr '09

06 Apr '09

Full_Name: Alexander Version: 2.4.11 OS: Fedora 10 URL: Submission from: (NULL) (213.150.1.77) Hello, I would like to install OpenLDAP 2.4.11 on Fedora FC10. It seems that it comes with BDB Berkeley DB 4.7.25 I experience an error during make that seems to be related with a wrong version. is this combination supported? should I install an older version of the database? I used the last stable version of OpenLDAP. br, alex make [...] make[3]: Entering directory `/etc/openldap-2.4.11/servers/slapd/back-bdb' rm -f version.c ../../../build/mkversion -v "2.4.11" back_bdb > version.c /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -D_GNU_SOURCE -c init.c cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -D_GNU_SOURCE -c init.c -o init.o init.c: In function 'bdb_db_open': init.c:509: error: 'DB_ENV' has no member named 'lk_handle' init.c: In function 'bdb_back_initialize': init.c:752: warning: passing argument 1 of 'db_env_set_func_yield' from incompatible pointer type make[3]: *** [init.lo] Error 1 make[3]: Leaving directory `/etc/openldap-2.4.11/servers/slapd/back-bdb' make[2]: *** [.backend] Error 1 make[2]: Leaving directory `/etc/openldap-2.4.11/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/etc/openldap-2.4.11/servers' make: *** [all-common] Error 1

1 0

Re: (ITS#6044) AnonCVS not working
by hyc＠symas.com 05 Apr '09

05 Apr '09

evaristojosec(a)yahoo.es wrote: > Full_Name: Evaristo Camarero > Version: Not relevant > OS: Fedora Core 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.7) > > > I am trying to access to the OpenLDAP repository but it is not possible doing > it > > cvs -d :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP login > Logging in to :pserver:anonymous@cvs.openldap.org:2401/repo/OpenLDAP > CVS password: > cvs [login aborted]: end of file from server (consult above messages if any) Several of the OpenLDAP.org services were down for a system upgrade. Everything should now be up though. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs