openldap-bugs May 2009

openldap-bugs@openldap.org

42 participants
159 discussions

(ITS#6092) correct string problem in guess_service_principal()
by mikbec＠web.de 04 May '09

04 May '09

Full_Name: Mike Becher Version: HEAD of 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/mike-becher-090504.libraries-libldap-gssapi… Submission from: (NULL) (84.150.168.64) patch file name: mike-becher-090504.libraries-libldap-gssapi.2.patch patch subject: correct string problem in guess_service_principal() patch description: When GSSAPI option GSSAPI_ALLOW_REMOTE_PRINCIPAL is switched on then string provided by "givenstr" will be used as principal name. But length of string counted in "svc_principal_size" is one letter to less. This patch corrects this problem, allocates memory for one more character to get space for '\0' and sets it.

1 0

(ITS#6091) missing implementation of "switch off" functionality of GSSAPI OPTIONS
by mikbec＠web.de 04 May '09

04 May '09

Full_Name: Mike Becher Version: HEAD of 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/mike-becher-090504.libraries-libldap-gssapi… Submission from: (NULL) (84.150.168.64) patch file name: mike-becher-090504.libraries-libldap-gssapi.1.patch patch subject: missing implementation of "switch off" functionality of GSSAPI OPTIONS patch description: Like manual pages of "ldap.conf (5)" describe in section GSSAPI OPTIONS it should be able to activate and/or deactivate options GSSAPI_SIGN, GSSAPI_ENCRYPT, and GSSAPI_ALLOW_REMOTE_PRINCIPAL. But functionality to switch off such a feature is not implemented. This patch adds the "switch off" functionality.

1 0

Re: (ITS#6084) ppolicy should allow scheduled password expiration
by Guillaume.Rousse＠inria.fr 04 May '09

04 May '09

Howard Chu a écrit : > Since the ppolicy module's behavior is dictated by the Behera draft, any > suggestions for changes in this area should probably first be raised on > the ietf-ldapext mailing list. Right, but openldap implementation already have extension, such pwdCheckModule. Additional extension could be implemented, before getting standardized. Also, the ietf-ldapext seems to be an highly-technical list, and I don't feel confortable enough to post this kind of request directly there. Discussing various limitations of ppolicy among openldap users first would probably allow openldap core team to suggest a more polished extension request themselves. -- BOFH excuse #287: Telecommunications is downshifting.

1 0

Re: (ITS#6090) slapd locks up; all slapd worker threads blocking on mutex acquisition in bdb_cache_lru_link()
by jwm＠horde.net 04 May '09

04 May '09

On Fri, 01 May 2009 15:10:46 -0700, Howard Chu wrote: > It seems you may need to recompile BerkeleyDB with debugging enabled (and > with -fno-omit-frame-pointer) to get a useful trace from this. This is > looking more like a BDB locking issue than an OpenLDAP issue. Done. Now we wait. > If you still have the environment, db_stat -CA would be helpful. slapd has been restarted since, so the lock statistics won't be useful. I've modified our harness to get them automatically with the backtrace. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#6074) SEGV in pthread_mutex_lock()
by richton＠nbcs.rutgers.edu 03 May '09

03 May '09

On Sun, 3 May 2009, Howard Chu wrote: >> data is null, p is null. > > And the trace shows data = 0x12cd3e0f0. What are you looking at? Sorry about that...despite appearances, I actually know that NULL != "". Guess this is what I get for writing an e-mail on the way to the airport. Let's try: (dbx) print data data = 0x12cd3e0f0 (dbx) print *data *data = (void) (dbx) print p p = (nil) so dereferencing p->avl_data was the no go. Hopefully this is more sane...

1 0

Re: (ITS#6087) The LDAP server refused to perform the operation
by quanah＠zimbra.com 03 May '09

03 May '09

--On Friday, May 01, 2009 11:13 AM +0000 damariris(a)gmail.com wrote: > Full_Name: Damaris > Version: 2.2.20 > OS: ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.38.79.241) Usage questions should be sent to openldap-software(a)openldap.org. I see no bug here. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6074) SEGV in pthread_mutex_lock()
by hyc＠symas.com 03 May '09

03 May '09

Aaron Richton wrote: > On Sat, 2 May 2009, Howard Chu wrote: > >> Fixed in HEAD. You should probably sync up with cache.c too; the tests Quanah >> and I have been running seem to like this better. > > 2.4.16 + synced back-bdb from head. NULL strncmp: There's no strncmp in this trace. This is a different symptom than before. > > t@14 (l@14) terminated by signal SEGV (no mapping at the fault address) > Current function is avl_insert > 125 cmp = fcmp( data, p->avl_data )> 0; > (dbx) where > current thread: t@14 > =>[1] avl_insert(root = 0x12c9e52c0, data = 0x12cd3e0f0, fcmp = 0x1001a1e90 =&`slapd`cache.c`bdb_rdn_cmp(const void *v_e1, const void *v_e2), fdup = 0x100273f00 =&avl_dup_error(void *left, void *right)), line 125 in "avl.c" > [2] hdb_cache_find_parent(op = 0x131b07390, txn = 0x132f36090, id = 12937U, res = 0xffffffff45e7e848), line 595 in "cache.c" > [3] hdb_cache_find_id(op = 0x131b07390, tid = 0x132f36090, id = 12937U, eip = 0xffffffff45e7e848, flag = 0, lock = 0xffffffff45e7e7f8), line 906 in "cache.c" > [4] hdb_search(op = 0x131b07390, rs = 0xffffffff45fff998), line 706 in "search.c" > [5] glue_sub_search(op = 0x131b07390, rs = 0xffffffff45fff998, b0 = 0xffffffff45ffeda8, on = 0x1106e0dd0), line 342 in "backglue.c" > [6] glue_op_search(op = 0x131b07390, rs = 0xffffffff45fff998), line 465 in "backglue.c" > [7] overlay_op_walk(op = 0x131b07390, rs = 0xffffffff45fff998, which = op_search, oi = 0x1106e1010, on = 0x1106e0dd0), line 659 in "backover.c" > [8] over_op_func(op = 0x131b07390, rs = 0xffffffff45fff998, which = op_search), line 721 in "backover.c" > [9] over_op_search(op = 0x131b07390, rs = 0xffffffff45fff998), line 743 in "backover.c" > [10] fe_op_search(op = 0x131b07390, rs = 0xffffffff45fff998), line 366 in "search.c" > [11] overlay_op_walk(op = 0x131b07390, rs = 0xffffffff45fff998, which = op_search, oi = 0x1106e16d0, on = (nil)), line 669 in "backover.c" > [12] over_op_func(op = 0x131b07390, rs = 0xffffffff45fff998, which = op_search), line 721 in "backover.c" > [13] over_op_search(op = 0x131b07390, rs = 0xffffffff45fff998), line 743 in "backover.c" > [14] do_search(op = 0x131b07390, rs = 0xffffffff45fff998), line 217 in "search.c" > [15] connection_operation(ctx = 0xffffffff45fffc20, arg_v = 0x131b07390), line 1097 in "connection.c" > [16] connection_read_thread(ctx = 0xffffffff45fffc20, argv = 0xbf), line 1223 in "connection.c" > [17] ldap_int_thread_pool_wrapper(xpool = 0x11062b6a0), line 663 in "tpool.c" > > data is null, p is null. And the trace shows data = 0x12cd3e0f0. What are you looking at? -- -- 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

Re: (ITS#6090) slapd locks up; all slapd worker threads blocking on mutex acquisition in bdb_cache_lru_link()
by jwm＠horde.net 01 May '09

01 May '09

On Fri, May 01, 2009 at 03:00:26PM -0700, Howard Chu wrote: > jwm(a)horde.net wrote: >> Full_Name: John Morrissey >> Version: 2.4.16 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92) >> >> After a couple days of uptime, slapd no longer responds to incoming >> connections (the connection would be accepted, but all LDAP operations >> would block). All worker threads seem to be blocking on mutex acquisition >> in bdb_cache_lru_link(). One thread was chewing lots of CPU. >> >> Backtrace is below. I also have a ~1.7GB core if it's deemed useful; I'll >> keep it around for a week or two. This is with BDB 4.7.25+all three >> patches. > > Interesting trace, it looks like all the active threads are waiting for > the mutex but apparently none of them owns it. Can you please provide the > contents of the mutex? e.g. > thread 14 > frame 3 > print *mutex (gdb) fra 3 #3 0xb7eec1cd in ldap_pvt_thread_mutex_lock (mutex=0x940a2cc) at /tmp/buildd/openldap-2.4.16/libraries/libldap_r/thr_posix.c:296 296 return ERRVAL( pthread_mutex_lock( mutex ) ); (gdb) print *mutex $1 = {__data = {__lock = 2, __count = 0, __owner = 6372, __kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, __size = "\002\000\000\000\000\000\000\000###30\000\000\000\000\000\000\001\000\000\000\000\000\000", __align = 2} LWP 6372 is the thread trying to do BDB lock promotion. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#6090) slapd locks up; all slapd worker threads blocking on mutex acquisition in bdb_cache_lru_link()
by hyc＠symas.com 01 May '09

01 May '09

hyc(a)symas.com wrote: > jwm(a)horde.net wrote: >> Full_Name: John Morrissey >> Version: 2.4.16 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92) >> >> >> After a couple days of uptime, slapd no longer responds to incoming connections >> (the connection would be accepted, but all LDAP operations would block). All >> worker threads seem to be blocking on mutex acquisition in bdb_cache_lru_link(). >> One thread was chewing lots of CPU. >> >> Backtrace is below. I also have a ~1.7GB core if it's deemed useful; I'll keep >> it around for a week or two. This is with BDB 4.7.25+all three patches. >> > Interesting trace, it looks like all the active threads are waiting for the > mutex but apparently none of them owns it. Can you please provide the contents > of the mutex? e.g. > thread 14 > frame 3 > print *mutex Ah, I missed this before, your thread 3 is inside a BerkeleyDB lock function. There's nothing useful in the trace for thread 3 though. It seems you may need to recompile BerkeleyDB with debugging enabled (and with -fno-omit-frame-pointer) to get a useful trace from this. This is looking more like a BDB locking issue than an OpenLDAP issue. If you still have the environment, db_stat -CA would be helpful. -- -- 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

Re: (ITS#6090) slapd locks up; all slapd worker threads blocking on mutex acquisition in bdb_cache_lru_link()
by hyc＠symas.com 01 May '09

01 May '09

jwm(a)horde.net wrote: > Full_Name: John Morrissey > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92) > > > After a couple days of uptime, slapd no longer responds to incoming connections > (the connection would be accepted, but all LDAP operations would block). All > worker threads seem to be blocking on mutex acquisition in bdb_cache_lru_link(). > One thread was chewing lots of CPU. > > Backtrace is below. I also have a ~1.7GB core if it's deemed useful; I'll keep > it around for a week or two. This is with BDB 4.7.25+all three patches. > Interesting trace, it looks like all the active threads are waiting for the mutex but apparently none of them owns it. Can you please provide the contents of the mutex? e.g. thread 14 frame 3 print *mutex -- -- 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:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2009