openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

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

09 Apr '09

OK, this is my first crash since moving to 2.4.16: Slightly different from the previous ones, but is coming through pcache.c:remove_from_template and, according to slapd log, was removing queries from cache when crash occurred: Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 5 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 26 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 4 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 25 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 3 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 24 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 2 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 23 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 1 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 22 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 0 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 21 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e6eb0 Here's the backtrace: Program terminated with signal 11, Segmentation fault. #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) at pcache.c:694 694 return pcache_filter_cmp( q1->first, q2->first ); (gdb) bt #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) at pcache.c:694 #1 0x08199b6d in tavl_delete (root=0x825d7d0, data=0xb1f0e900, fcmp=0x81764d8 <pcache_query_cmp>) at tavl.c:202 #2 0x08177ab4 in remove_from_template (qc=0xb1f0e900, template=0x94e6eb0) at pcache.c:1302 #3 0x0817b57d in consistency_check (ctx=0xb44201d0, arg=0x9537c50) at pcache.c:2597 #4 0x0819fd01 in ldap_int_thread_pool_wrapper (xpool=0x94a8fa0) at tpool.c:663 #5 0x009c546b in start_thread () from /lib/libpthread.so.0 #6 0x0091cdbe in clone () from /lib/libc.so.6 (gdb) (gdb) p q1->first $3 = (Filter *) 0xb1f0d4c0 (gdb) p q2->first Cannot access memory at address 0x83e58959 Let me know what else would be useful from this backtrace. 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 08 Apr '09

08 Apr '09

luca.scamoni(a)sys-net.it ha scritto: > 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 Another update The issue seems to be in the order in which rwm and syncprov are invoked. If the slapd.conf file contains: database hdb [...] overlay rwm [...] overlay syncprov [...] the modification causes slapd to segfault if the two overlays are swapped database hdb [...] overlay syncprov [...] overlay rwm [...] it doesn't. So there is something wrong in the interaction between these two 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 07 Apr '09

07 Apr '09

On Apr 7, 2009, at 5:50 AM, h.b.furuseth(a)usit.uio.no wrote: > Kurt(a)OpenLDAP.org writes: >> 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). > > I'm getting backups of my last weeks' mail now, roughly in STMP stream > format as far as I can tell. Will send it later. Need to filter out > the openldap messages and check that I got it right first. The archives were backfilled late yesterday.... -- Kurt

1 0

Re: (ITS#6048) All mailing list archives have stopped at March
by Duncan.Gibb＠SiriusIT.co.uk 07 Apr '09

07 Apr '09

h.b.furuseth(a)usit.uio.no wrote: KZ> Unfortunately, there will be a hole in the archives unless someone KZ> happens to have a decent mbox archives for backfill HBF> I'm getting backups of my last weeks' mail now, roughly in STMP HBF> stream format as far as I can tell. Will send it later. We should have archives of traffic on openldap-its, -technical, -devel, and -bugs (under Cyrus, so not in mbox format). Give me a shout if you would like them exported. Cheers Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063

1 0

Re: (ITS#6048) All mailing list archives have stopped at March
by h.b.furuseth＠usit.uio.no 07 Apr '09

07 Apr '09

Kurt(a)OpenLDAP.org writes: > 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). I'm getting backups of my last weeks' mail now, roughly in STMP stream format as far as I can tell. Will send it later. Need to filter out the openldap messages and check that I got it right first. -- Hallvard

1 0

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

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