openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

>> It returns whatever returned by sasl_getprop(); it should be a pointer >> to >> a zero-terminated string within the SASL context (you don't have to free >> it, but it may be invalidated when the context is destroyed). > > It seems "you don't have to free it" was the clue! > Well, it rather means you must not free it. That's exactly what I meant :) > Ah, nice! web2ldap does not show anonymous anymore when binding to MS AD > with > SASL/GSSAPI. :-) > > Any chance to get this into 2.4.18? Please... ;-) I don't consider this a critical change, so I wouldn't object. Having said this, I wouldn't cry if 2.4.18 is ready and the maintainers do not want to re-package it just because of this fix :) p.

1 0

Re: (ITS#6200)
by imf＠u.washington.edu 18 Aug '09

18 Aug '09

On Tue, 18 Aug 2009, masarati(a)aero.polimi.it wrote: >> Sorry about the stripped trace. I forgot that the install procedure >> always strips the binaries... >> >> Okay, with our stress profile it takes ~36 hours to fail. I always >> start with a clean db rebuild before each run. Each failure produces >> the same traceback: >> >> (gdb) where >> #0 0x00b97410 in __kernel_vsyscall () >> #1 0x00471d80 in raise () from /lib/libc.so.6 >> #2 0x00473691 in abort () from /lib/libc.so.6 >> #3 0x0046b1fb in __assert_fail () from /lib/libc.so.6 >> #4 0x0808d532 in ch_malloc (size=4436335) at ch_malloc.c:57 > > ^^^ this really looks like memory exhaustion while trying to malloc a > large chunk (>4MB). Can you tell, by printing e->e_name, whether it's > correct that the server was modifying a large entry? int entry_encode(Entry *e, struct berval *bv) { ber_len_t len, dnlen, ndnlen, i; int nattrs, nvals; Attribute *a; unsigned char *ptr; Debug( LDAP_DEBUG_TRACE, "=> entry_encode(0x%08lx): %s\n", (long) e->e_id, e->e_dn, 0 ); dnlen = e->e_name.bv_len; ndnlen = e->e_nname.bv_len; entry_partsize( e, &len, &nattrs, &nvals, 1 ); bv->bv_len = len; bv->bv_val = ch_malloc(len); (gdb) p *e $8 = {e_id = 343637, e_name = {bv_len = 0, bv_val = 0x822169c ""}, e_nname = {bv_len = 0, bv_val = 0x822169c ""}, e_attrs = 0x208d270c, e_ocflags = 256, e_bv = {bv_len = 6598587, bv_val = 0x1ddb5008 "\021"}, e_private = 0x9ad5ce0} (gdb) p *bv $2 = {bv_len = 4436293, bv_val = 0x1 <Address 0x1 out of bounds>} (gdb) p nattrs $6 = 16 (gdb) p nvals $7 = 270294 Well, according to e->e_name, e_dn (e_name.bv_val) is empty, so this is likely bogus. We do have some large member entries (>100K) in our test profile, however none add up to anywhere near >4M. Tracy > > p. > >> #5 0x08079ad2 in entry_encode (e=0x3a3dac0, bv=0x3a3d9b0) at entry.c:742 >> #6 0x0815240e in bdb_id2entry_put (be=0x3a3dca0, tid=0xbc6f7378, >> e=0x3a3dac0, flag=0) at id2entry.c:54 >> #7 0x08152508 in hdb_id2entry_update (be=0x3a3dca0, tid=0xbc6f7378, >> e=0x3a3dac0) at id2entry.c:90 >> #8 0x08106374 in hdb_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:611 >> #9 0x080ea38e in overlay_op_walk (op=0xdabbc28, rs=0x3a3f0e4, >> which=op_modify, oi=0x8be2788, on=0x0) at backover.c:669 >> #10 0x080ea543 in over_op_func (op=0xdabbc28, rs=0x3a3f0e4, >> which=op_modify) at backover.c:721 >> #11 0x080ea60b in over_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at >> backover.c:755 >> #12 0x08089151 in fe_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at >> modify.c:301 >> #13 0x08088b90 in do_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:175 >> #14 0x0806be8f in connection_operation (ctx=0x3a3f1d0, arg_v=0xdabbc28) at >> connection.c:1115 >> #15 0x0806c3cf in connection_read_thread (ctx=0x3a3f1d0, argv=0x1a) at >> connection.c:1251 >> #16 0x081d8fa9 in ldap_int_thread_pool_wrapper (xpool=0x8b941b0) at >> tpool.c:685 >> #17 0x0043749b in start_thread () from /lib/libpthread.so.0 >> #18 0x0051a42e in clone () from /lib/libc.so.6 > > >

1 0

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by michael＠stroeder.com 18 Aug '09

18 Aug '09

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>>> libldap should be capable of returning SASL username obtained with >>>> sasl_getprop( sasl_context, SASL_USERNAME, ... ) as result of >>>> ldap_get_option() >>> Added to HEAD (LDAP_OPT_X_SASL_USERNAME); please test. Thanks, p. >> Does it simply return a string like LDAP_OPT_URI, >> LDAP_OPT_X_TLS_CACERTFILE etc.? > > It returns whatever returned by sasl_getprop(); it should be a pointer to > a zero-terminated string within the SASL context (you don't have to free > it, but it may be invalidated when the context is destroyed). It seems "you don't have to free it" was the clue! Well, it rather means you must not free it. Ah, nice! web2ldap does not show anonymous anymore when binding to MS AD with SASL/GSSAPI. :-) Any chance to get this into 2.4.18? Please... ;-) Ciao, Michael.

1 0

Re: (ITS#6262) Wrap gmtime(3) for re-entrancy
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

Just to clarify: there is NO re-entrancy issue. This is essentially about code re-factoring. p.

1 0

Re: (ITS#6262) Wrap gmtime(3) for re-entrancy
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> Open issues: > > - check for re-entrancy of the WIN32 version of lutil_gettime() > > - allow apps to use gmtime(3)/localtime(3) in re-entrant manner when the > _r > replacements are not available (the mutex is no longer exposed) - add function checks to configure. p.

1 0

(ITS#6262) Wrap gmtime(3) for re-entrancy
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.235) Submitted by: ando gmtime(3)/gmtime_r(3), localtime(3)/localtime_r(3) can be wrapped in a single place, getting rid of lots of #defines and so. A patch is ready that either provides a re-entrant wrapper or defines the re-entrant functions as macros. Open issues: - check for re-entrancy of the WIN32 version of lutil_gettime() - allow apps to use gmtime(3)/localtime(3) in re-entrant manner when the _r replacements are not available (the mutex is no longer exposed) p.

1 0

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> masarati(a)aero.polimi.it wrote: >>> libldap should be capable of returning SASL username obtained with >>> sasl_getprop( sasl_context, SASL_USERNAME, ... ) as result of >>> ldap_get_option() >> >> Added to HEAD (LDAP_OPT_X_SASL_USERNAME); please test. Thanks, p. > > Does it simply return a string like LDAP_OPT_URI, > LDAP_OPT_X_TLS_CACERTFILE etc.? It returns whatever returned by sasl_getprop(); it should be a pointer to a zero-terminated string within the SASL context (you don't have to free it, but it may be invalidated when the context is destroyed). See ITS#6260 about documenting the behavior with these options :) Note that SASL documentation is itself relatively poor in this area. I could infer the above from code samples 'round, for which is which. p.

1 0

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by michael＠stroeder.com 18 Aug '09

18 Aug '09

masarati(a)aero.polimi.it wrote: >> libldap should be capable of returning SASL username obtained with >> sasl_getprop( sasl_context, SASL_USERNAME, ... ) as result of >> ldap_get_option() > > Added to HEAD (LDAP_OPT_X_SASL_USERNAME); please test. Thanks, p. Does it simply return a string like LDAP_OPT_URI, LDAP_OPT_X_TLS_CACERTFILE etc.? Ciao, Michael.

1 0

Re: (ITS#6200)
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> Sorry about the stripped trace. I forgot that the install procedure > always strips the binaries... > > Okay, with our stress profile it takes ~36 hours to fail. I always > start with a clean db rebuild before each run. Each failure produces > the same traceback: > > (gdb) where > #0 0x00b97410 in __kernel_vsyscall () > #1 0x00471d80 in raise () from /lib/libc.so.6 > #2 0x00473691 in abort () from /lib/libc.so.6 > #3 0x0046b1fb in __assert_fail () from /lib/libc.so.6 > #4 0x0808d532 in ch_malloc (size=4436335) at ch_malloc.c:57 ^^^ this really looks like memory exhaustion while trying to malloc a large chunk (>4MB). Can you tell, by printing e->e_name, whether it's correct that the server was modifying a large entry? p. > #5 0x08079ad2 in entry_encode (e=0x3a3dac0, bv=0x3a3d9b0) at entry.c:742 > #6 0x0815240e in bdb_id2entry_put (be=0x3a3dca0, tid=0xbc6f7378, > e=0x3a3dac0, flag=0) at id2entry.c:54 > #7 0x08152508 in hdb_id2entry_update (be=0x3a3dca0, tid=0xbc6f7378, > e=0x3a3dac0) at id2entry.c:90 > #8 0x08106374 in hdb_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:611 > #9 0x080ea38e in overlay_op_walk (op=0xdabbc28, rs=0x3a3f0e4, > which=op_modify, oi=0x8be2788, on=0x0) at backover.c:669 > #10 0x080ea543 in over_op_func (op=0xdabbc28, rs=0x3a3f0e4, > which=op_modify) at backover.c:721 > #11 0x080ea60b in over_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at > backover.c:755 > #12 0x08089151 in fe_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at > modify.c:301 > #13 0x08088b90 in do_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:175 > #14 0x0806be8f in connection_operation (ctx=0x3a3f1d0, arg_v=0xdabbc28) at > connection.c:1115 > #15 0x0806c3cf in connection_read_thread (ctx=0x3a3f1d0, argv=0x1a) at > connection.c:1251 > #16 0x081d8fa9 in ldap_int_thread_pool_wrapper (xpool=0x8b941b0) at > tpool.c:685 > #17 0x0043749b in start_thread () from /lib/libpthread.so.0 > #18 0x0051a42e in clone () from /lib/libc.so.6

1 0

Re: (ITS#6200)
by imf＠u.washington.edu 18 Aug '09

18 Aug '09

Sorry about the stripped trace. I forgot that the install procedure always strips the binaries... Okay, with our stress profile it takes ~36 hours to fail. I always start with a clean db rebuild before each run. Each failure produces the same traceback: (gdb) where #0 0x00b97410 in __kernel_vsyscall () #1 0x00471d80 in raise () from /lib/libc.so.6 #2 0x00473691 in abort () from /lib/libc.so.6 #3 0x0046b1fb in __assert_fail () from /lib/libc.so.6 #4 0x0808d532 in ch_malloc (size=4436335) at ch_malloc.c:57 #5 0x08079ad2 in entry_encode (e=0x3a3dac0, bv=0x3a3d9b0) at entry.c:742 #6 0x0815240e in bdb_id2entry_put (be=0x3a3dca0, tid=0xbc6f7378, e=0x3a3dac0, flag=0) at id2entry.c:54 #7 0x08152508 in hdb_id2entry_update (be=0x3a3dca0, tid=0xbc6f7378, e=0x3a3dac0) at id2entry.c:90 #8 0x08106374 in hdb_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:611 #9 0x080ea38e in overlay_op_walk (op=0xdabbc28, rs=0x3a3f0e4, which=op_modify, oi=0x8be2788, on=0x0) at backover.c:669 #10 0x080ea543 in over_op_func (op=0xdabbc28, rs=0x3a3f0e4, which=op_modify) at backover.c:721 #11 0x080ea60b in over_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at backover.c:755 #12 0x08089151 in fe_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:301 #13 0x08088b90 in do_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:175 #14 0x0806be8f in connection_operation (ctx=0x3a3f1d0, arg_v=0xdabbc28) at connection.c:1115 #15 0x0806c3cf in connection_read_thread (ctx=0x3a3f1d0, argv=0x1a) at connection.c:1251 #16 0x081d8fa9 in ldap_int_thread_pool_wrapper (xpool=0x8b941b0) at tpool.c:685 #17 0x0043749b in start_thread () from /lib/libpthread.so.0 #18 0x0051a42e in clone () from /lib/libc.so.6 --- Tracy Stenvik University Computing Services 354843. University of Washington email: imf(a)u.washington.edu voice: (206) 685-3344 On Thu, 23 Jul 2009, Howard Chu wrote: > imf(a)u.washington.edu wrote: >> The changes made to 2.4.17 seem to have fixed the crashes in the caching >> module. Thanks for that. >> >> We still are able to crash 2.4.17, however. It only happens after a heavy >> load is placed on the producer for>24 hours continuous. Unfortunately, >> we've not been able to get good tracebacks. They all look like this, >> >> (gdb) where >> #0 0x00869410 in __kernel_vsyscall () >> #1 0x00390d80 in raise () from /lib/libc.so.6 >> #2 0x00392691 in abort () from /lib/libc.so.6 >> #3 0x0038a1fb in __assert_fail () from /lib/libc.so.6 >> #4 0x0808d532 in malloc () >> #5 0x0822c93f in ?? () >> #6 0x0822c933 in ?? () >> #7 0x00000039 in ?? () >> #8 0x0822c908 in ?? () >> #9 0x00000000 in ?? () >> >> The producer slowly grows its memory footprint. I can't tell if it's from >> just normal operations or memory leaks. I suspect it's a little of both. >> The end result, as you can see from the core above, is that there's likely >> some corrupted (or unfreed) memory somewhere. Sorry I can't nail it down >> further. > > There's not enough information here. > > An assert is always accompanied by an error message on stderr; we need to see > the actual error message. > > There are no symbols in the stack trace pertaining to slapd itself. You seem > to be running a stripped binary. Please provide a trace using a non-stripped > binary that was compiled with -g (debug symbols enabled). >> >> The load profile that we placed on the server is documented in my prior >> report. See above. > > > -- > -- 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