- openldap-bugs - openldap.org

(ITS#6438) usage of invalid mutexint in syncprov
by richton＠nbcs.rutgers.edu 04 Jan '10

04 Jan '10

Full_Name: Aaron Richton Version: RE24 20091217 (2.4.21) OS: Solaris 9 URL: :wq Submission from: (NULL) (128.6.31.135) dec_mutexint was called with a NULL parameter while running the test suite. Unfortunately, the only evidence of this is a core file.

1 0

Re: (ITS#6437) sl_malloc issues
by hyc＠symas.com 04 Jan '10

04 Jan '10

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> Nobody uses the pool code. I would suggest you profile it against the stack >> code before spending any time fixing it. > > The pool version crashes if I divide SLAP_SLAB_SIZE by 16 or multiply > the allocated amounts by 17. The stack version stays happy. I also > tried RE23 and rev 1.48 in case of code rot. (Should have tried > OpenLDAP 2.2, but would need to install an old Berkeley DB.) Adding a > sl_malloc fallback to ch_malloc instead of returning NULL didn't help. > > Anyway, I tried this because I assume the pool version is intended to > reduce the number of sl_malloc fallbacks to ch_malloc, but that almost > never happens in 'make test' with the current SLAP_SLAB_SIZE. Which > made that aspect hard to test. > > Also the pool version does a number of ch_mallocs for administration and > ch_frees them at reset. If the idea is to reduce ch_mallocs, it should > keep these blocks around. (Or allocate them with the slab.) Except the > 'slab_object's It only needs cleanup if the slab size changes, which > slapd never seems to do. This stuff was originally written to grow the slab as needed, but it was also being very braindead and would have kept a lot of excess memory lying around so I dropped that. So right, currently the slab size doesn't change. -- -- 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#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 04 Jan '10

04 Jan '10

> > OK. Another question - you're only using NSS_InitContext() for client > initialization. Any particular reason not to always use it? > I had coded around a bug in NSS_InitContext that caused it not to work in server mode - the MozNSS guys are aware of this issue - I'm waiting on the fix. > Also in tlsm_ctx_free() is it safe to pass a NULL to NSS_ShutdownContext()? I > think these two lines should be enclosed in "if (c->tc_initctx) {}" I'll change it to check for NULL.

1 0

Re: (ITS#4033) Enhancement requests : Need LDIF parsing API's
by rmeggins＠redhat.com 04 Jan '10

04 Jan '10

See also http://www.openldap.org/its/index.cgi/Software%20Enhancements?id=6194;selec… An API that returned LDAPMod ** and LDAPControl ** would be sufficient for all cases, including the LDAP ADD and any LDAP modify cases. The current discussion revolves around exposing the high level LDAPMod and LDAPControl APIs to the lower level libldif, or just passing the parsed values as lists of struct berval *

1 0

Re: (ITS#6437) sl_malloc issues
by h.b.furuseth＠usit.uio.no 04 Jan '10

04 Jan '10

hyc(a)symas.com writes: > Nobody uses the pool code. I would suggest you profile it against the stack > code before spending any time fixing it. The pool version crashes if I divide SLAP_SLAB_SIZE by 16 or multiply the allocated amounts by 17. The stack version stays happy. I also tried RE23 and rev 1.48 in case of code rot. (Should have tried OpenLDAP 2.2, but would need to install an old Berkeley DB.) Adding a sl_malloc fallback to ch_malloc instead of returning NULL didn't help. Anyway, I tried this because I assume the pool version is intended to reduce the number of sl_malloc fallbacks to ch_malloc, but that almost never happens in 'make test' with the current SLAP_SLAB_SIZE. Which made that aspect hard to test. Also the pool version does a number of ch_mallocs for administration and ch_frees them at reset. If the idea is to reduce ch_mallocs, it should keep these blocks around. (Or allocate them with the slab.) Except the 'slab_object's It only needs cleanup if the slab size changes, which slapd never seems to do. -- Hallvard

1 0

Re: (ITS#6437) sl_malloc issues
by h.b.furuseth＠usit.uio.no 02 Jan '10

02 Jan '10

hyc(a)symas.com writes: > h.b.furuseth(a)usit.uio.no wrote: > Go ahead and commit. In working pieces if necessary. We'll pick and choose... Committed one batch of fixes/tweaks, hopefully independent after the first one or two. Next batch will have to walk all over some of these. >> * Why is there a slap_sl_mem_detach() when there is no way to reattach >> it? As far as I can tell all the caller can do is to inspect/clean up >> the returned slab_heap itself. > > It was originally implemented in 2.2 to support psearch for sync replication. > It was obsoleted when the syncprov overlay was written in 2.3, we just never > deleted it. Go ahead and delete it. Actually I just realized the context can be used thread-less just fine, even if it's only relevant if any 3rd party modules do it. Might as well keep it in RE24, just in case. But I'll move structs slap_object and slap_heap back to sl_malloc.c, so such modules cannot mess with them. > (And remember, the point of sl_malloc is that a heap here doesn't need > any special cleanup - just free it and forget it.) Not quite, due to the ch_malloc fallbacks. Anyway, I've committed some comments with my understanding of the package. >> * Some failures assert(0)/exit() like ch_malloc.c, but without giving a >> Debug() message first. > > don't really care... I do, I've had silent exits from slapd before and hated it. -- Hallvard

1 0

Re: (ITS#6437) sl_malloc issues
by h.b.furuseth＠usit.uio.no 02 Jan '10

02 Jan '10

hyc(a)symas.com writes: > Go ahead and commit. In working pieces if necessary. We'll pick and choose... Thanks. Will do. > Nobody uses the pool code. I would suggest you profile it against the stack > code before spending any time fixing it. Right, that and detach was what I wondered most about. Beyond just "with enough changes, some will be bugs":-) Well, the current pool code blocks the "ber_len_t -> 32-bit" space optimization, which would import the alignment problem to 64-bit hosts. Will profile first. When I get time. >> * Regarding code duplication, the #ifdef SLAP_NO_SL_MALLOC code >> duplicates the !ctx code. Make that if(<enum No_sl_malloc> && !ctx) >> and the #ifdefs can be killed. > > I would personally prefer no runtime checks, and all compile-time checks. Right, but if(compile-time constant) is a compile-time check on a decent compiler. Otherwise we shouldn't be using '#define foobar do { ... } while(0)' trick to allow ';' after a macro. -- Hallvard

1 0

Re: (ITS#6437) sl_malloc issues
by hyc＠symas.com 02 Jan '10

02 Jan '10

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux x86_64 > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Here are a number of bugs and other issues with slapd/sl_malloc.c, and > one for ber_memcalloc. Some for RE24, likely some for RE25, but I don't > know where to cut off for RE24? (Waiting for someone to say...) Go ahead and commit. In working pieces if necessary. We'll pick and choose... > > * It claims to align on 2*sizeof(int) boundaries, but it looks like > stack:realloc and pool:mem_create can un-align to (2n+1)*sizeof(int) > boundaries on 32-bit hosts, where sizeof(ber_len_t) == sizeof(int). > > A slap_sl_realloc() fix for the stack implementation is to replace > size += pad + sizeof( ber_len_t ); > size&= ~pad; > with > size = ((size + pad)& ~pad) + sizeof( ber_len_t ); > however see the optimizations and tweaks below. Fine. > For the pool implementation, maybe slap_sl_mem_create() can just set > so->so_ptr = (char *) sh->sh_base + sizeof(ber_len_t) % (pad+1); > Unless that messes up its expectations of how much space is left, I > haven't checked. Should mem_create size be increased accordingly? Nobody uses the pool code. I would suggest you profile it against the stack code before spending any time fixing it. > Unfortunately sl_malloc.c exports its internals, so I don't know what > kind of fix would affect it: > > * Why is there a slap_sl_mem_detach() when there is no way to reattach > it? As far as I can tell all the caller can do is to inspect/clean up > the returned slab_heap itself. It was originally implemented in 2.2 to support psearch for sync replication. It was obsoleted when the syncprov overlay was written in 2.3, we just never deleted it. Go ahead and delete it. (And remember, the point of sl_malloc is that a heap here doesn't need any special cleanup - just free it and forget it.) > * slap_sl_mem_create() switching implementation stack<->pool on an old > memctx slab can crash or leak, it runs the wrong cleanup code. > > Fix: Remove code duplication, rearrange. The pool cleanup duplicates > slap_sl_mem_destroy(), except the final frees. Let destroy(key=NULL,) > mean don't free and call that. Also the create/destroy pool branches > duplicate the stack branches. > > * However, will the pool (i.e. non-stack) implementation ever be used? > If not, a simpler fix to some of this is to delete it. OTOH if it > someday may be used, hopefully some of these cleanups will be leaving > it a bit more correct, easier to read, and faster. Though I haven't > gone to the drastic step of studying it to see how it works. > > Or we could #ifdef it out by default. It's unclear to me why this is > a run-time argument to the create function instead of instead of a > -D<compiler flag>, why would the caller care? Dunno. I guess it was for quicker turnaround during testing. But afaik only Jong ever tested/used it, and no one else has spent any time on it. #if'ing it all out is fine with me. Of course, if you find that it's actually better performing than the stack version, then we can #if out the stack code instead. > > #define SLAP_SLAB_MODE<undef or 1:stack, 0:pool: -1:support both>. > #define SLAP_SLAB_ISSTACK(stack)<stack if both, else SLAP_SLAB_MODE> > > * Regarding code duplication, the #ifdef SLAP_NO_SL_MALLOC code > duplicates the !ctx code. Make that if(<enum No_sl_malloc> && !ctx) > and the #ifdefs can be killed. I would personally prefer no runtime checks, and all compile-time checks. > * Also we can throw the #ifdef NO_THREADS/#else/#endif code out to two > macros #define GET_MEMCTX()/SET_MEMCTX(). right. > * The "enough room?" test (ptr + size< endptr) is invalid, can e.g. > wrap around, when there is not enough room. Use (size< endptr-ptr). ok. > * Some failures assert(0)/exit() like ch_malloc.c, but without giving a > Debug() message first. don't really care... > * The slap_sl_malloc() pool implementation can return NULL on failure > at comment "FIXME: missing return; guessing...". For consistency it > should exit on failure like the rest of sl_malloc.c and ch_malloc.c. don't care, unless we decide to keep the pool code. Go ahead and commit. > * Realloc(last block) when the following free space is not big enough, > does not move sh_last and reclaim free space properly. > > * slap_sl_calloc()/ber_memcalloc() do not catch<count>*<size> overflow: > ber_len_t total = n * size; > if (!n&& total/n == size)<allocate...>; > > That can be optimized a bit, if anyone cares: > > #define LIM_SQRT(t) /* some value< sqrt(max value of unsigned type t) */ \ > ((0UL|(t)-1)>>31>>31> 1 ? ((t)1<<32) - 1 : \ > (0UL|(t)-1)>>31 ? 65535U : (0UL|(t)-1)>>15 ? 255U : 15U) > ... > /* sqrt test = slight optimization: often avoids the division */ > if ((n | size)<= LIM_SQRT(ber_len_t) || !n || total/n == size) ... > > * slap_sl_<malloc/realloc> increase size before proceeding, they should > reduce it before falling back to ch_malloc and for Debug messages. > > Space optimizations/cleanup: > > * To save space on 64-bit hosts: We can store store sizes (head, tail) > in 4-byte typedef ber_uint_t slap_sl_size_t instead of a ber_len_t. > > After fixing the misalignment issue above, however. > > * Also the stack implementation does not need to allocate the tail. > It can store the "block is freed" bit in the head of the _next_ block, > and only store a tail in free blocks (i.e. if that bit is set). > > I think that does add a bit of code, though it is convenient for the > "reclaim freed blocks at sh_last" code in slap_sl_free(). > > * Ignoring last point, the "reclaim" code can in any case be simplified: > /* mark it free */ > p[-1] = size |= 1; > /* reclaim free space off tail */ > if (sh->sh_last == p) { > do { > p = (slap_sllen_t*) ((char*) p - size + 1) - 1; > size = p[-1]; > } while (size& 1); > sh->sh_last = p; > } > > * Realloc can check if previous or next block is free before giving up > and doing malloc/copy/free. That does multiply its code size though. > Dunno if it's a good idea. Needs testing/timing, I guess. > > * Aligning with (size& ~pad) is wrong for non-two's complement signed > pad, it should be (size& -(pad + 1)) aka (size& -Alignment). > > All right, so I'm nitpicking. I just dislike unportable code which > isn't even simpler than the portable variant. -- -- 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

(ITS#6437) sl_malloc issues
by h.b.furuseth＠usit.uio.no 02 Jan '10

02 Jan '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Here are a number of bugs and other issues with slapd/sl_malloc.c, and one for ber_memcalloc. Some for RE24, likely some for RE25, but I don't know where to cut off for RE24? (Waiting for someone to say...) * It claims to align on 2*sizeof(int) boundaries, but it looks like stack:realloc and pool:mem_create can un-align to (2n+1)*sizeof(int) boundaries on 32-bit hosts, where sizeof(ber_len_t) == sizeof(int). A slap_sl_realloc() fix for the stack implementation is to replace size += pad + sizeof( ber_len_t ); size &= ~pad; with size = ((size + pad) & ~pad) + sizeof( ber_len_t ); however see the optimizations and tweaks below. For the pool implementation, maybe slap_sl_mem_create() can just set so->so_ptr = (char *) sh->sh_base + sizeof(ber_len_t) % (pad+1); Unless that messes up its expectations of how much space is left, I haven't checked. Should mem_create size be increased accordingly? Unfortunately sl_malloc.c exports its internals, so I don't know what kind of fix would affect it: * Why is there a slap_sl_mem_detach() when there is no way to reattach it? As far as I can tell all the caller can do is to inspect/clean up the returned slab_heap itself. * slap_sl_mem_create() switching implementation stack<->pool on an old memctx slab can crash or leak, it runs the wrong cleanup code. Fix: Remove code duplication, rearrange. The pool cleanup duplicates slap_sl_mem_destroy(), except the final frees. Let destroy(key=NULL,) mean don't free and call that. Also the create/destroy pool branches duplicate the stack branches. * However, will the pool (i.e. non-stack) implementation ever be used? If not, a simpler fix to some of this is to delete it. OTOH if it someday may be used, hopefully some of these cleanups will be leaving it a bit more correct, easier to read, and faster. Though I haven't gone to the drastic step of studying it to see how it works. Or we could #ifdef it out by default. It's unclear to me why this is a run-time argument to the create function instead of instead of a -D<compiler flag>, why would the caller care? #define SLAP_SLAB_MODE <undef or 1:stack, 0:pool: -1:support both>. #define SLAP_SLAB_ISSTACK(stack) <stack if both, else SLAP_SLAB_MODE> * Regarding code duplication, the #ifdef SLAP_NO_SL_MALLOC code duplicates the !ctx code. Make that if(<enum No_sl_malloc> && !ctx) and the #ifdefs can be killed. * Also we can throw the #ifdef NO_THREADS/#else/#endif code out to two macros #define GET_MEMCTX()/SET_MEMCTX(). * The "enough room?" test (ptr + size < endptr) is invalid, can e.g. wrap around, when there is not enough room. Use (size < endptr-ptr). * Some failures assert(0)/exit() like ch_malloc.c, but without giving a Debug() message first. * The slap_sl_malloc() pool implementation can return NULL on failure at comment "FIXME: missing return; guessing...". For consistency it should exit on failure like the rest of sl_malloc.c and ch_malloc.c. * Realloc(last block) when the following free space is not big enough, does not move sh_last and reclaim free space properly. * slap_sl_calloc()/ber_memcalloc() do not catch <count>*<size> overflow: ber_len_t total = n * size; if (!n && total/n == size) <allocate...>; That can be optimized a bit, if anyone cares: #define LIM_SQRT(t) /* some value < sqrt(max value of unsigned type t) */ \ ((0UL|(t)-1) >>31>>31 > 1 ? ((t)1 <<32) - 1 : \ (0UL|(t)-1) >>31 ? 65535U : (0UL|(t)-1) >>15 ? 255U : 15U) ... /* sqrt test = slight optimization: often avoids the division */ if ((n | size) <= LIM_SQRT(ber_len_t) || !n || total/n == size) ... * slap_sl_<malloc/realloc> increase size before proceeding, they should reduce it before falling back to ch_malloc and for Debug messages. Space optimizations/cleanup: * To save space on 64-bit hosts: We can store store sizes (head, tail) in 4-byte typedef ber_uint_t slap_sl_size_t instead of a ber_len_t. After fixing the misalignment issue above, however. * Also the stack implementation does not need to allocate the tail. It can store the "block is freed" bit in the head of the _next_ block, and only store a tail in free blocks (i.e. if that bit is set). I think that does add a bit of code, though it is convenient for the "reclaim freed blocks at sh_last" code in slap_sl_free(). * Ignoring last point, the "reclaim" code can in any case be simplified: /* mark it free */ p[-1] = size |= 1; /* reclaim free space off tail */ if (sh->sh_last == p) { do { p = (slap_sllen_t*) ((char*) p - size + 1) - 1; size = p[-1]; } while (size & 1); sh->sh_last = p; } * Realloc can check if previous or next block is free before giving up and doing malloc/copy/free. That does multiply its code size though. Dunno if it's a good idea. Needs testing/timing, I guess. * Aligning with (size & ~pad) is wrong for non-two's complement signed pad, it should be (size & -(pad + 1)) aka (size & -Alignment). All right, so I'm nitpicking. I just dislike unportable code which isn't even simpler than the portable variant. * pad and order_start can be compile-time enums instead of computed at run time (if any compilers do not optimize it away already): enum { Align = 2*sizeof(int), Align_log2 = 1 + (Align>2) + (Align>4) + (Align>8) + (Align>16), pad = Align - 1, /* but drop that, it's just as easy to use Align */ order_start = Align_log2 /* which also can be dropped */ }; ... assert(Align == 1 << Align_log2); /* Adding head+tail preserves alignment */ assert(2*sizeof(ber_len_t) % Align == 0); * The pool code can be cleaned up by basing 'order' on Align-sized chunks instead of byte-sized chunks, i.e. subtract order_start from sh->sh_maxorder, order/i/j variables. Also subtract 1 from mem_create:order, so that 'order' means the same as 'order' elsewhere. (Straightforward replacement, no need to invoke the brain and understand the code:-) * The pool implementation sometimes does 1<<foo where it should do (ber_len_t)1<<foo or 1U<<foo.

1 0

Re: (ITS#4868) Binary Attribute Patch(es)
by hyc＠symas.com 30 Dec '09

30 Dec '09

vargok(a)yahoo.com wrote: > (I realize this is ridiculously late, but... well, better late than never, and this is the first I've gotten back to it.) > > Yes! It's working now in 2.4.x as expected, via the new userCertificate > stub data provided by example. FWIW, it appears to be working fine with the PostgreSQL example files as well. > > Unfortunately, it was never "back" ported to 2.3. We're currently using 2.3.43 as part of RHEL-5. Any chance it could get back-ported into the 2.3 branch? Development on 2.3 ended about a year ago. > Thanks, > Kevin > > > > ----- Original Message ---- >> From: Pierangelo Masarati<ando(a)sys-net.it> >> To: vargok(a)yahoo.com >> Cc: openldap-its(a)openldap.org >> Sent: Wed, April 11, 2007 7:06:57 PM >> Subject: Re: (ITS#4868) Binary Attribute Patch(es) >> >> ando(a)sys-net.it wrote: >> >>> Right. Time permitting, I'll check why back-sql behaves differently >>> and, in case, how to fix it. >> >> HEAD should be working as expected, now. I've also updated mysql and >> psql sql-test000 (the latter is untested, though). >> >> Please test and report. p. >> >> >> >> Ing. Pierangelo Masarati >> OpenLDAP Core Team >> >> SysNet s.r.l. >> via Dossi, 8 - 27100 Pavia - ITALIA >> http://www.sys-net.it >> --------------------------------------- >> Office: +39 02 23998309 >> Mobile: +39 333 4963172 >> Email: pierangelo.masarati(a)sys-net.it >> --------------------------------------- -- -- 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#4868) Binary Attribute Patch(es)
by vargok＠yahoo.com 30 Dec '09

30 Dec '09

(I realize this is ridiculously late, but... well, better late than never, and this is the first I've gotten back to it.) Yes! It's working now in 2.4.x as expected, via the new userCertificate stub data provided by example. FWIW, it appears to be working fine with the PostgreSQL example files as well. Unfortunately, it was never "back" ported to 2.3. We're currently using 2.3.43 as part of RHEL-5. Any chance it could get back-ported into the 2.3 branch? Thanks, Kevin ----- Original Message ---- > From: Pierangelo Masarati <ando(a)sys-net.it> > To: vargok(a)yahoo.com > Cc: openldap-its(a)openldap.org > Sent: Wed, April 11, 2007 7:06:57 PM > Subject: Re: (ITS#4868) Binary Attribute Patch(es) > > ando(a)sys-net.it wrote: > > > Right. Time permitting, I'll check why back-sql behaves differently > > and, in case, how to fix it. > > HEAD should be working as expected, now. I've also updated mysql and > psql sql-test000 (the latter is untested, though). > > Please test and report. p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > ---------------------------------------

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 30 Dec '09

30 Dec '09

On Wed, Dec 30, 2009 at 09:04:12AM +0100, Helge Milde wrote: >I just enabled trace loglevel, perhaps that might give us a clue on what's going on. Slapd just stopped working again. Here's the (annotated) log for viewing and/or downloading: http://www.pastie.org/761198.txt Does this give you any clues? Tell me if I can do anything else to help. -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 30 Dec '09

30 Dec '09

On Tue, Dec 29, 2009 at 11:00:25AM -0800, Howard Chu wrote: >Sorry, your issue was closed since we hadn't received any feedback >from you in a couple of months. > >The last trace you sent shows nothing unusual, just a bunch of >threads all waiting to write on their respective connections. If the core dump backtrace wasn't helpful, then please tell me so; I thought I had given you sufficient feedback, and that you were working on it. >Have you tried the .21 release yet? No.. I might do that next week. Is there anything else that I can do? I just enabled trace loglevel, perhaps that might give us a clue on what's going on. >-- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Helge Milde, 69701808 www.monsternett.no

1 0

(ITS#6247)
by daniel＠pluta.biz 29 Dec '09

29 Dec '09

Hi, I did just some small cleanups, but added no new functionality. I've extracted the minimalistic slapd-api modifications in an extra file called "now_slapd.patch" also contained in the tgz. The code compiles and runs against todays version of "HEAD". The new tgz-file can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-now-091229-1.tgz Cheers Daniel

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by hyc＠symas.com 29 Dec '09

29 Dec '09

helge(a)monsternett.no wrote: > Would be nice to get some feedback on this one.. > Were using a core dump sufficient? If so, was the information helpful at all? > If there's anything more I could do, please say so. > Sorry, your issue was closed since we hadn't received any feedback from you in a couple of months. The last trace you sent shows nothing unusual, just a bunch of threads all waiting to write on their respective connections. Have you tried the .21 release yet? -- -- 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#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 29 Dec '09

29 Dec '09

Would be nice to get some feedback on this one.. Were using a core dump sufficient? If so, was the information helpful at all? If there's anything more I could do, please say so. -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by hyc＠symas.com 23 Dec '09

23 Dec '09

rmeggins(a)redhat.com wrote: > The ldif code does not currently have knowledge of any of the higher > level LDAP data types such as LDAPMod or LDAPControl - some of the > proposals would have the ldif API return these objects - Do we really > want to introduce this higher level knowledge into the relatively low > level libldif, along with the dependency on libldap? I think in order > to do this properly, we would have to introduce a new LDAP API e.g. > ldap_mods_from_ldif(const char *ldifstr, LDAPMod***, LDAPControl***) or > something like that - something that would parse the given ldif record > into those higher level data types. Should have mentioned this sooner; this ITS needs to be merged with ITS#4033. -- -- 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: Re : Re : ITS#6434
by masarati＠aero.polimi.it 22 Dec '09

22 Dec '09

KISTER RAPHAEL wrote: > I re-test with servers/slapd/overlays/rwm.c in version 1.125 and it works fine. I don't test with the next version. Fine. The other modifications are not strictly related to your issue, but rather to modifications to olcRwmMap using back-config. p.

1 0

Re : Re : ITS#6434
by kraph＠yahoo.com 22 Dec '09

22 Dec '09

Hello,=0A=0AI re-test with servers/slapd/overlays/rwm.c in version 1.125 an= d it works fine. I don't test with the next=A0version.=0A=0ARaphael KISTER= =0A=0A=0A

1 0

Re: (ITS#6435) Hidden schema elements
by michael＠stroeder.com 22 Dec '09

22 Dec '09

Kurt Zeilenga wrote: > On Dec 21, 2009, at 12:35 PM, Michael Ströder wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> Yes, it has long been our practice not to publish schema elements which = >>> are not yet well standardized. This would include any element which = >>> carries a OpenLDAP.666 OID. >>> >>> The idea being that use of such attributes should be limited to early = >>> adopters and such. >> Sorry, but this practice is inconsequent. > > That's your opinion. My opinion is that we should avoid publishing > ''works in progress'' in production systems. Works in progress, by their > very nature, are subject to change without notice. If you'd really like to avoid issues with attributes being falsely handled by the client because the semantics changed you would especially also have to change the attribute type's NAME. Because that's what regular naive LDAP clients look for. A fully schema-aware client like web2ldap discovers OID changes and handles things correctly. E.g. in web2ldap plugins are preferrably registered by OID (besides some exceptions in case of missing schema descriptions). If the semantics changes and you assign a new OID web2ldap would not naively just treat it the same way. One has to explicitly register a plugin class for the new OID, off course after checking that semantics are the same then. Opposite to that if e.g. the semantics of entryCSN changes and you assign a new OID of a hidden schema description there's no chance to discover that. That's simply bad and therefore I won't follow your arguments at all. BTW: OpenLDAP also prefers NAME handling over OIDs. So with an OpenLDAP deployment changing the OID of a schema descriptions has no effect. But changing the NAME does. That's what I think is inconsequent: The current practice does not avoid issues. It only makes things worse. Ciao, Michael.

1 0

Re: (ITS#6435) Hidden schema elements
by Kurt＠OpenLDAP.org 21 Dec '09

21 Dec '09

On Dec 21, 2009, at 12:35 PM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> Yes, it has long been our practice not to publish schema elements = which =3D >> are not yet well standardized. This would include any element which = =3D >> carries a OpenLDAP.666 OID. >>=20 >> The idea being that use of such attributes should be limited to early = =3D >> adopters and such. >=20 > Sorry, but this practice is inconsequent. That's your opinion. My opinion is that we should avoid publishing = ''works in progress'' in production systems. Works in progress, by = their very nature, are subject to change without notice. > The attributes are returned in LDAP > responses Generally because the client asked for more than it should have. = Clients really shouldn't generally be asking for * and/or +. The two exceptions are clients which are servers attempting to = server-to-server replication and clients operated by directory = administrators. Clients which are intended to support various user applications really = should ask only for what they designed to consume. > and therefore a client should be able to look up the attribute type > description in the schema e.g. to determine the syntax. I disagree. Schema may not be made available to the client for any = number of reasons. The X.500 and LDAP specifications allow for this. >=20 > Some of the OIDs are now with .666 for years. Each time this topic is = raised > nothing happens... That's because (in general) the ''works in progress'' have not be = finalized. If something hasn't changed in years, then maybe it's time = to finalize it and, in doing so, assign it final OID. -- Kurt=

1 0

Re: (ITS#6435) Hidden schema elements
by michael＠stroeder.com 21 Dec '09

21 Dec '09

Kurt(a)OpenLDAP.org wrote: > Yes, it has long been our practice not to publish schema elements which = > are not yet well standardized. This would include any element which = > carries a OpenLDAP.666 OID. > > The idea being that use of such attributes should be limited to early = > adopters and such. Sorry, but this practice is inconsequent. The attributes are returned in LDAP responses and therefore a client should be able to look up the attribute type description in the schema e.g. to determine the syntax. Some of the OIDs are now with .666 for years. Each time this topic is raised nothing happens... Ciao, Michael.

1 0

Re: (ITS#6436) olcRwmMap atomic modification
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

masarati(a)aero.polimi.it wrote: > olcRwmMap modification via back-config is not atomic; direct insert/delete not > allowed. A patch that implements support for this is proposed. p. The patch makes modification of this attribute consistent (all changes succeeed, or none); if modifications to olcRwmMap are followed by modifications to other attrs within the same write operation, the whole operation is not atomic. This less than ideal behavior is common to many operations allowed by back-config, though. Please test. p.

1 0

(ITS#6436) olcRwmMap atomic modification
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando olcRwmMap modification via back-config is not atomic; direct insert/delete not allowed. A patch that implements support for this is proposed. p.

1 0

Re: (ITS#6435) Hidden schema elements
by michael＠stroeder.com 21 Dec '09

21 Dec '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: Irrelevant > URL: > Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) > Submitted by: rein > > Some of the operational attributes defined in the slapd source are hidden from > the clients unless slapd is compiled with LDAP_DEVEL enabled. Still, some of > these elements are used in the database (as in the authz* and monitor related > attributes). Yes, see also: http://www.openldap.org/its/index.cgi?findid=5573 http://www.openldap.org/its/index.cgi?findid=5574 http://www.openldap.org/its/index.cgi?findid=5576 IIRC also a bunch of attribute types used in back-config which makes back-config almost unusable with a stock schema aware client. The standard answer by Kurt and others is that as along as an experimental OID with .666 is used a schema description should be hidden. I strongly disagree with that though. > This causes my schema-aware application to complain when it sees > (or worse tries to modify) these attributes. (Sigh!) I also had to add several work-arounds to web2ldap regarding this. > A patch that adds a new optional define that can be used to disable the schema > hiding without enabling LDAP_DEVEL is coming. Looking forward to this being committed. > A better fix would be to not hide those schema elements that is actually > being used.. Amen. Ciao, Michael.

1 0

Re: (ITS#6435) Hidden schema elements
by Kurt＠OpenLDAP.org 21 Dec '09

21 Dec '09

On Dec 21, 2009, at 8:09 AM, rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: Irrelevant > URL:=20 > Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) > Submitted by: rein >=20 >=20 > Some of the operational attributes defined in the slapd source are = hidden from > the clients unless slapd is compiled with LDAP_DEVEL enabled. Yes, it has long been our practice not to publish schema elements which = are not yet well standardized. This would include any element which = carries a OpenLDAP.666 OID. The idea being that use of such attributes should be limited to early = adopters and such. > Still, some of > these elements are used in the database (as in the authz* and monitor = related > attributes). This causes my schema-aware application to complain when = it sees > (or worse tries to modify) these attributes. >=20 > A patch that adds a new optional define that can be used to disable = the schema > hiding without enabling LDAP_DEVEL is coming. A better fix would be = to not hide > those schema elements that is actually being used.. It may be that the particular schema elements simply shouldn't be behind = LDAP_DEVEL any longer, possibly because a permanent OID has yet to be = assigned to now production code. >=20 > Rein >=20

1 0

Re: Re : ITS#6434
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

KISTER RAPHAEL wrote: > Hello, > > I make a test with servers/slapd/overlays/rwm.c version 1.124. It works fine. Thank you very much for your help. I've re-fixed the problem in a different way; please re-test. Thanks, p.

1 0

Re: (ITS#6435) Hidden schema elements
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

rein(a)OpenLDAP.org wrote: > A better fix would be to not hide > those schema elements that is actually being used.. As far as I can tell, OpenLDAP's policy with respect to hiding schema definitions consists in un-hiding only those that are documented in standards track documents, or are for internal use and thus documented internally (e.g. back-config related). So the "right" fix would be to work at formalizing and submitting documents to stardards track. p.

1 0

(ITS#6435) Hidden schema elements
by rein＠OpenLDAP.org 21 Dec '09

21 Dec '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) Submitted by: rein Some of the operational attributes defined in the slapd source are hidden from the clients unless slapd is compiled with LDAP_DEVEL enabled. Still, some of these elements are used in the database (as in the authz* and monitor related attributes). This causes my schema-aware application to complain when it sees (or worse tries to modify) these attributes. A patch that adds a new optional define that can be used to disable the schema hiding without enabling LDAP_DEVEL is coming. A better fix would be to not hide those schema elements that is actually being used.. Rein

1 0

Re : ITS#6434
by kraph＠yahoo.com 21 Dec '09

21 Dec '09

Hello,=0A=0AI=A0make a test=A0with servers/slapd/overlays/rwm.c=A0version= =A0=A01.124. It works fine. Thank you very much for your help.=0A=0ABest re= gards,=0A=A0Raphael KISTER=0A=0A=0A=0A----- Message d'origine ----=0ADe : P= ierangelo Masarati <masarati(a)aero.polimi.it>=0A=C0 : KISTER RAPHAEL <kraph@= yahoo.com>; openldap-its(a)openldap.org=0AEnvoy=E9 le : Lun 21 D=E9cembre 200= 9, 13 h 08 min 31 s=0AObjet=A0: ITS#6434=0A=0AThe problem has been fixed in= HEAD (servers/slapd/overlays/rwm.c 1.122 -> 1.223); please test and report= .=A0 Thanks, p.=0A=0A=0A=0A

1 0

ITS#6434
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

The problem has been fixed in HEAD (servers/slapd/overlays/rwm.c 1.122 -> 1.223); please test and report. Thanks, p.

1 0

(ITS#6434) Problem with rewrite overlay
by kraph＠yahoo.com 21 Dec '09

21 Dec '09

Full_Name: Raphaël KISTER Version: 2.4.20 OS: Linux CentOS 5.4 URL: http://www.raphael-kister.fr/openldap_its Submission from: (NULL) (88.184.63.204) I would like to use OpenLDAP as an Active Directory Proxy. I configure ldap backend and i rewrite some attributes and objectclass. When i test my configuration file, i get this error : config error processing olcOverlay={0}rwm,olcDatabase={2}ldap,cn=config: <olcRwmMap> handler exited with 1 slaptest: bad configuration directory! This is an extract of my config file : database ldap suffix dc=CNC,dc=LOCAL rootdn "cn=admin,cn=config" uri ldap://192.168.44.88:389 lastmod off acl-authcDN cn=admin,cn=config acl-passwd secret idassert-bind bindmethod="simple" binddn="CN=srv_ldap,OU=Services-account,OU=Administration,dc=CNC,dc=LOCAL" credentials="Azerty00" mode="legacy" overlay rwm #rwm-suffixmassage dc=CNC,dc=LOCAL rwm-map objectclass inetOrgPerson user rwm-map attribute uid sAMAccountName rwm-map attribute cn cn rwm-map attribute displayName displayName rwm-map attribute givenName givenName rwm-map attribute sn sn rwm-map attribute mail mail rwm-map attribute userPassword userPassword rwm-map attribute *

1 0

(ITS#6433) patch for the sha2 module: hash methods for passwords generation
by cdelfosse＠mandriva.com 21 Dec '09

21 Dec '09

Full_Name: Cédric Delfosse Version: HEAD OS: Mandriva Linux URL: ftp://ftp.openldap.org/incoming/cedric-delfosse-091221.patch Submission from: (NULL) (62.212.120.90) Hello, this patch allows to use the {SHA256}, {SHA384} and {SHA512} password schemes (provided by the sha2 module) with LDAP Password Modify Extended Operations. This patch contains the required hash methods. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Mandriva. Mandriva has not assigned rights and/or interest in this work to any party. I, Cédric Delfosse am authorized by Mandriva, my employer, to release this work under the following terms. Mandriva hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Regards, Cédric

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by hyc＠symas.com 19 Dec '09

19 Dec '09

rmeggins(a)redhat.com wrote: > You are right, Howard. It works as you described. I'm not sure what > happened in my testing. Mea culpa. > > This is a new patch with the SetURL changes backed out. > > ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200… OK. Another question - you're only using NSS_InitContext() for client initialization. Any particular reason not to always use it? Also in tlsm_ctx_free() is it safe to pass a NULL to NSS_ShutdownContext()? I think these two lines should be enclosed in "if (c->tc_initctx) {}" -- -- 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#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 18 Dec '09

18 Dec '09

You are right, Howard. It works as you described. I'm not sure what happened in my testing. Mea culpa. This is a new patch with the SetURL changes backed out. ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200…

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by hyc＠symas.com 18 Dec '09

18 Dec '09

rmeggins(a)redhat.com wrote: >>> I also had to call >>> SSL_SetURL in order to put the correct hostname in the SSL socket for cert >>> validation. >> >> I explicitly withheld the hostname to force our own cert validation function >> to be used. The NSS hostname validator's behavior is inconsistent with the >> LDAP spec. >> > That's the tlsm_session_chkhost() function? The problem is that the > chkhost function is called too late - NSS attempts to perform the > verification during the handshake process - by the time > ldap_pvt_tls_check_hostname() is called in ldap_int_tls_start(), it's > too late - NSS has failed - ldap_int_tls_connect() has returned an error. That should not happen, since tlsm_bad_cert_handler() causes the bad hostname result to be returned as Success. That gives us the chance to check it on our own. It worked in my tests before... -- -- 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#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 18 Dec '09

18 Dec '09

This is a new patch, which #defines HAVE_NSS_INITCONTEXT based on the NSS version. ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200…

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 18 Dec '09

18 Dec '09

> > Thanks for the patch. > > Just blindly #defining HAVE_NSS_INITCONTEXT is no good. Isn't there an NSS > version symbol we can check in the preprocessor, to make sure it's 3.12.5 or > newer? Otherwise we'll need an autoconf test for the existence of the > NSS_InitCOntext() function. > Ok. I'll change it to check for NSS version >= 3.12.5 > > This allows apps and libraries to initialize NSS from different contexts. > I've > > also cleaned up some of the code around PEM file support. I also had to > call > > SSL_SetURL in order to put the correct hostname in the SSL socket for cert > > validation. > > I explicitly withheld the hostname to force our own cert validation function > to be used. The NSS hostname validator's behavior is inconsistent with the > LDAP spec. > That's the tlsm_session_chkhost() function? The problem is that the chkhost function is called too late - NSS attempts to perform the verification during the handshake process - by the time ldap_pvt_tls_check_hostname() is called in ldap_int_tls_start(), it's too late - NSS has failed - ldap_int_tls_connect() has returned an error.

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by hyc＠symas.com 18 Dec '09

18 Dec '09

rmeggins(a)redhat.com wrote: > Full_Name: Richard Megginson > Version: 2.4.20 > OS: Fedora 11 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200… > Submission from: (NULL) (76.113.111.209) > > > This patch adds support for the new NSS_InitContext() API (new in NSS 3.12.5). Thanks for the patch. Just blindly #defining HAVE_NSS_INITCONTEXT is no good. Isn't there an NSS version symbol we can check in the preprocessor, to make sure it's 3.12.5 or newer? Otherwise we'll need an autoconf test for the existence of the NSS_InitCOntext() function. > This allows apps and libraries to initialize NSS from different contexts. I've > also cleaned up some of the code around PEM file support. I also had to call > SSL_SetURL in order to put the correct hostname in the SSL socket for cert > validation. I explicitly withheld the hostname to force our own cert validation function to be used. The NSS hostname validator's behavior is inconsistent with the LDAP spec. -- -- 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

(ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 18 Dec '09

18 Dec '09

Full_Name: Richard Megginson Version: 2.4.20 OS: Fedora 11 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200… Submission from: (NULL) (76.113.111.209) This patch adds support for the new NSS_InitContext() API (new in NSS 3.12.5). This allows apps and libraries to initialize NSS from different contexts. I've also cleaned up some of the code around PEM file support. I also had to call SSL_SetURL in order to put the correct hostname in the SSL socket for cert validation. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not assigned rights and/or interest in this work to any party. I, Richard Megginson am authorized by Red Hat, Inc., my employer, to release this work under the following terms. Red Hat, Inc. hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by masarati＠aero.polimi.it 17 Dec '09

17 Dec '09

> Forgot to enclose the URL. > > http://folk.uio.no/hbf/OpenLDAP/slapreply-draft2.diff At a first glance, your patch makes sense. I see your concern, this approach is definitely fragile. However, I see two points: - the code is not just modified by everyone, so we can count on paying relative attention to what is done, as soon as there are clear guidelines - we should probably produce some indications about how code needs to be used. I'm not thinking about a comprehensive programming guide, but some clear guidelines about writing safe code in critical areas like this would be of help. In cases like this, I'd really prefer to be able to exploit OOP and data abstraction as in C++. p.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by hyc＠symas.com 17 Dec '09

17 Dec '09

rmeggins(a)redhat.com wrote: > I think this could be accomplished in one of two ways: > 1) Just have libldif return lists of struct berval* for the various data > parsed. The caller would be responsible for turning these into LDAPMod > or LDAPControl structures - the advantage is that libldif doesn't have > to know about any of these higher level structures > 2) Have libldif create LDAPMod and LDAPControl - I think this could be > accomplished by having ldif.c #include<ldap.h> to pull in the > definitions of LDAPMod and LDAPControl - would this be ok? Let's move this discussion to the openldap-devel mailing list. I'm thinking (2) is OK but I'd like to hear from other developers / potential users of this library. -- -- 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#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 17 Dec '09

17 Dec '09

I think this could be accomplished in one of two ways: 1) Just have libldif return lists of struct berval* for the various data parsed. The caller would be responsible for turning these into LDAPMod or LDAPControl structures - the advantage is that libldif doesn't have to know about any of these higher level structures 2) Have libldif create LDAPMod and LDAPControl - I think this could be accomplished by having ldif.c #include <ldap.h> to pull in the definitions of LDAPMod and LDAPControl - would this be ok?

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 16 Dec '09

16 Dec '09

The ldif code does not currently have knowledge of any of the higher level LDAP data types such as LDAPMod or LDAPControl - some of the proposals would have the ldif API return these objects - Do we really want to introduce this higher level knowledge into the relatively low level libldif, along with the dependency on libldap? I think in order to do this properly, we would have to introduce a new LDAP API e.g. ldap_mods_from_ldif(const char *ldifstr, LDAPMod***, LDAPControl***) or something like that - something that would parse the given ldif record into those higher level data types.

1 0

Re: (ITS#6403) crash with translucent + back-null
by h.b.furuseth＠usit.uio.no 16 Dec '09

16 Dec '09

I wrote: > I'll fix translucent for now, but I assume a saner fix would be to > change that "calling convention" - which I suspect exists in the first > place because I once gave a bug just like this the same minimal fix. [Reopening ITS...] And I have no idea why I didn't remove that back-null assert as well, though there was undoubtedly a reason. Anyway, it's gone now. -- Hallvard

1 0

Re: (ITS#6431) LDAP Server disabled
by quanah＠zimbra.com 15 Dec '09

15 Dec '09

--On Tuesday, December 15, 2009 3:32 AM +0000 yimnara(a)khaouchuly.com wrote: > Full_Name: Yim Nara > Version: 2.1.0 > OS: Window 2003 server > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (124.248.180.59) > > > LDAP server Disabled I'm not sure why you think this is an OpenLDAP issue, nor do I see any indication of a bug report here. If you have questions about using OpenLDAP, please use the openldap-software(a)openldap.org list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 15 Dec '09

15 Dec '09

Forgot to enclose the URL. http://folk.uio.no/hbf/OpenLDAP/slapreply-draft2.diff

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 15 Dec '09

15 Dec '09

[Copying some discussion from IRC, and adding some more] I'm a bit nervous about doing more than minimal fixes to this until we do something major, because it's so broken. Fix one bit and maybe something will pop up another place - i.e. a regression. Also following existing practice can mean fix one bug into a different bug, which Ando recently did for ITS#6423. (dynlist resets MUSTRELEASE but doesn't obey it, rwm works around a similar bug in rwm or dynlist.) Though he got other fixes right. Anyway: To repeat, the main problems with the current code: * Code does not always clean up properly, leaving e.g. flags behind. * Code which does clean up sometimes does it halfway, e.g. it resets MUSTBEFREED/MUSTRELEASE but not MODIFIABLE. So, no wonder there are unwanted MODIFIABLE flags hanging about (ITS#6423). Or it dup()s an entry but does not release the old one. * op_*() generally expects SlapReply to be preinitialized. That worked before overlays, but now modules (backends, overlays) inherit values that the previous module did not clean up during an operation. Howard suggested that we should restore that - code which puts something into a SlapReply should ensure it's taken out again. I've started on that in the enclosed patch, but on second thought I think that's not the right fix because it's the most fragile solution: Practically every module which depends on it can break if some other module gets it wrong. OTOH, modules can't just reset SlapReply since some of it is input values to op_*(): - Controls can be set in backend_check_restrictions() before the call to op_*(). - dynlist.c sets r.sr_attr_flags before calling o.o_bd->be_search(), I haven't looked at what effect that has. I'm thinking modules should instead initialize SlapReply.sr_u and maybe some sr_flags themselves instead of depending on preinit, but I don't know when I'll get back to doing something about that. Xmas coming... So anyway, here is a quick patch which actually tries to be rather conservative, sans a bunch of RS_ASSERT() lines which can be safely deleted in real code. It only addresses sr_entry and sporadically attrs, not sr_refs/ctrls. It passes make test for me. Please review. Where updates to flags are broken and needs fixing, I change to use the new function rs_ensure_entry_modifiable() etc, but I leave correct updates alone - as well as some updates where I don't know which overlay should be passed to these function. Description of changes: All over the place: Clear MUSTBEFREED/MUSTRELEASE by clearing all of REP_ENTRY_MASK, not just the particular flag. Reset attrs, entry, flags a number of places. (Not very consistently, sorry.) Lots of RS_ASSERT()s for debugging. Only defined when LDAP_DEVEL. proto-slap.h, result.c: Move RS_ASSERT(), add rs_flush_entry(). result.c: MODIFIABLE is independent of MUSTBEFREED - the modifiable entry can e.g. be on the stack. result.c, extended.c: When changing sr->sr_type to extended/sasl, flush sr_un (usually the entry) first, since another member of the union will be used. For this reason, updates to sr_type are "suspicious" code to be avoided, so some code elsewhere is changed to initialize it to REP_RESULT rather than setting it to that after initialization. bconfig.c, servers/slapd/syncrepl.c: Avoid reusing SlapReply a number of places where that's easy. slap.h: Cast the REP_... flags to slap_mask_t, so ~REP_... will work right. back-bdb/search.c: Delay setting rs->sr_entry until we know it'll be used. (IIRC made a difference around a paged results response.) back-shell/result.c, back-sock/result.c: Set MUSTBEFREED before sending, obey it afterwards. overlays/constraint.c, overlays/pcache.c: Drop nulling of fields that were just nulled by initialization. overlays/dynlist.c: When "stealing" an entry from SlapReply, grab and reset the flags that go with it, so it can be properly freed/released. Restore the flags and entry later, then obey the flags (release/free). Do this unconditionally, it happens only once per SlapReply anyway. overlays/pcache.c: Obey and reset entry flags properly. Remove unused SlapReply parameters to some functions - did this for readibility while trying to figure out what was going on. overlays/sssvlv.c: Since setting MUSTRELEASE before sending, obey it afterwards. overlays/translucent.c: Reset flags properly too when releasing/freeing entry. Streamline translucent_search() loop to clarify ownership of entry. overlays/rwm.c, servers/slapd/slapi/slapi_pblock.c: Obey flags properly.

1 0

Re: Re: (ITS#6426) slapd crash with 'Bus error'
by a.afzali2003＠gmail.com 15 Dec '09

15 Dec '09

--001485f6da5ee30006047ac04fe7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Regards, -- afshin On Dec 15, 2009 11:58am, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Afshin, > Copy openldap-its(a)openldap.org on all you replies so they go into the bug > tracker, so that others can see them. > --Quanah > --On Tuesday, December 15, 2009 10:39 AM +0330 afshin afzali > a.afzali2003(a)gmail.com> wrote: > Hi Quanah, > Appreciate your help. Hope this be helpful. > -- afshin > [root@dc1 libexec]# gdb ./slapd core.12305 > GNU gdb Fedora (6.8-37.el5) > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu"... > Reading symbols from /lib64/libuuid.so.1...done. > Loaded symbols for /lib64/libuuid.so.1 > Reading symbols from /lib64/librt.so.1...done. > Loaded symbols for /lib64/librt.so.1 > Reading symbols from /lib64/libcrypt.so.1...done. > Loaded symbols for /lib64/libcrypt.so.1 > Reading symbols from /lib64/libnsl.so.1...done. > Loaded symbols for /lib64/libnsl.so.1 > Reading symbols from /lib64/libm.so.6...done. > Loaded symbols for /lib64/libm.so.6 > Reading symbols from /lib64/libpthread.so.0...done. > Loaded symbols for /lib64/libpthread.so.0 > Reading symbols from /usr/lib64/libstdc++.so.6...done. > Loaded symbols for /usr/lib64/libstdc++.so.6 > Reading symbols from /usr/lib64/libsasl2.so.2...done. > Loaded symbols for /usr/lib64/libsasl2.so.2 > Reading symbols from /lib64/libssl.so.6...done. > Loaded symbols for /lib64/libssl.so.6 > Reading symbols from /lib64/libcrypto.so.6...done. > Loaded symbols for /lib64/libcrypto.so.6 > Reading symbols from /lib64/libresolv.so.2...done. > Loaded symbols for /lib64/libresolv.so.2 > Reading symbols from /lib64/libgcc_s.so.1...done. > Loaded symbols for /lib64/libgcc_s.so.1 > Reading symbols from /lib64/libc.so.6...done. > Loaded symbols for /lib64/libc.so.6 > Reading symbols from /lib64/ld-linux-x86-64.so.2...done. > Loaded symbols for /lib64/ld-linux-x86-64.so.2 > Reading symbols from /lib64/libdl.so.2...done. > Loaded symbols for /lib64/libdl.so.2 > Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done. > Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 > Reading symbols from /usr/lib64/libkrb5.so.3...done. > Loaded symbols for /usr/lib64/libkrb5.so.3 > Reading symbols from /lib64/libcom_err.so.2...done. > Loaded symbols for /lib64/libcom_err.so.2 > Reading symbols from /usr/lib64/libk5crypto.so.3...done. > Loaded symbols for /usr/lib64/libk5crypto.so.3 > Reading symbols from /usr/lib64/libz.so.1...done. > Loaded symbols for /usr/lib64/libz.so.1 > Reading symbols from /usr/lib64/libkrb5support.so.0...done. > Loaded symbols for /usr/lib64/libkrb5support.so.0 > Reading symbols from /lib64/libkeyutils.so.1...done. > Loaded symbols for /lib64/libkeyutils.so.1 > Reading symbols from /lib64/libselinux.so.1...done. > Loaded symbols for /lib64/libselinux.so.1 > Reading symbols from /lib64/libsepol.so.1...done. > Loaded symbols for /lib64/libsepol.so.1 > Reading symbols from /lib64/libnss_files.so.2...done. > Loaded symbols for /lib64/libnss_files.so.2 > Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...done. > Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2 > Reading symbols from /usr/lib64/sasl2/libsasldb.so.2...done. > Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2 > Reading symbols from /usr/lib64/sasl2/liblogin.so.2...done. > Loaded symbols for /usr/lib64/sasl2/liblogin.so.2 > Reading symbols from /usr/lib64/sasl2/libplain.so.2...done. > Loaded symbols for /usr/lib64/sasl2/libplain.so.2 > Core was generated by `./slapd -d5'. > Program terminated with signal 11, Segmentation fault. > [New process 12313] > [New process 12314] > [New process 12312] > [New process 12311] > [New process 12310] > [New process 12309] > [New process 12308] > [New process 12307] > [New process 12305] > # 0 NdbTransaction::execute (this=0x15, > # aTypeOfExec=NdbTransaction::Rollback, > abortOption=NdbOperation::DefaultAbortOption, forceSend=0) > at NdbTransaction.cpp:278 > 278 NdbTransaction.cpp: No such file or directory. > in NdbTransaction.cpp > (gdb) thr apply all bt > Thread 9 (process 12305): > # 0 0x000000370e8077e5 in pthread_join () from /lib64/libpthread.so.0 > # 1 0x000000000059affb in ldap_pvt_thread_join (thread=1107417408, > thread_return=0x0) at thr_posix.c:197 > # 2 0x00000000004ba2a8 in slapd_daemon () at daemon.c:2835 > # 3 0x000000000049bfad in main (argc=2, argv=0x7fff78fd91e8) at > # main.c:950 > Current language: auto; currently c++ > Thread 8 (process 12307): > # 0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > # 1 0x000000000068a73b in my_sleep (m_seconds=) > at my_sleep.c:34 > # 2 0x00000000006b3ff0 in TransporterFacade::threadMainReceive > # (this=0xc7a6530) > at ../../../../storage/ndb/include/portlib/NdbSleep.h:31 > # 3 0x00000000006b4049 in runReceiveResponse_C (me=0x0) > at TransporterFacade.cpp:564 > # 4 0x00000000006a35de in ndb_thread_wrapper (_ss=0xc581620) at > # NdbThread.c:147 5 0x000000370e8064a7 in start_thread () from > # /lib64/libpthread.so.0 6 0x000000370e0d3c2d in clone () from > # /lib64/libc.so.6 > Thread 7 (process 12308): > # 0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > # 1 0x000000000068a73b in my_sleep (m_seconds=) > ---Type to continue, or q to quit--- > at my_sleep.c:34 > # 2 0x00000000006b2d0f in TransporterFacade::threadMainSend > # (this=0xc7a6530) > at ../../../../storage/ndb/include/portlib/NdbSleep.h:31 > # 3 0x00000000006b2d89 in runSendRequest_C (me=0x0) > at TransporterFacade.cpp:529 > # 4 0x00000000006a35de in ndb_thread_wrapper (_ss=0xc588670) at > # NdbThread.c:147 5 0x000000370e8064a7 in start_thread () from > # /lib64/libpthread.so.0 6 0x000000370e0d3c2d in clone () from > # /lib64/libc.so.6 > Thread 6 (process 12309): > # 0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > # 1 0x000000000068a73b in my_sleep (m_seconds=) > at my_sleep.c:34 > # 2 0x00000000006b9740 in ClusterMgr::threadMain (this=0xc7b8ce0) > at ../../../../storage/ndb/include/portlib/NdbSleep.h:31 > # 3 0x00000000006b98d9 in runClusterMgr_C (me=0x0) at ClusterMgr.cpp:50 > # 4 0x00000000006a35de in ndb_thread_wrapper (_ss=0xc5888b0) at > # NdbThread.c:147 5 0x000000370e8064a7 in start_thread () from > # /lib64/libpthread.so.0 6 0x000000370e0d3c2d in clone () from > # /lib64/libc.so.6 > Thread 5 (process 12310): > # 0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > # 1 0x000000000068a73b in my_sleep (m_seconds=) > ---Type to continue, or q to quit--- > at my_sleep.c:34 > # 2 0x00000000006c8738 in TransporterRegistry::start_clients_thread ( > this=0xc580c70) at > ../../../../../storage/ndb/include/portlib/NdbSleep.h:31 > # 3 0x00000000006c89e9 in run_start_clients_C (me=0x0) > at TransporterRegistry.cpp:1422 > # 4 0x00000000006a35de in ndb_thread_wrapper (_ss=0xc588a40) at > # NdbThread.c:147 5 0x000000370e8064a7 in start_thread () from > # /lib64/libpthread.so.0 6 0x000000370e0d3c2d in clone () from > # /lib64/libc.so.6 > Thread 4 (process 12311): > # 0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > # 1 0x00000000006a82d6 in SocketServer::doAccept (this=0xc7b8bd0) > at SocketServer.cpp:189 > # 2 0x00000000006a8612 in SocketServer::doRun (this=0xc7b8bd0) > at SocketServer.cpp:279 > # 3 0x00000000006a8639 in socketServerThread_C (_ss=0x1) > at SocketServer.cpp:231 > # 4 0x00000000006a35de in ndb_thread_wrapper (_ss=0xc581710) at > # NdbThread.c:147 5 0x000000370e8064a7 in start_thread () from > # /lib64/libpthread.so.0 6 0x000000370e0d3c2d in clone () from > # /lib64/libc.so.6 > Thread 3 (process 12312): > # 0 0x000000370e0d4018 in epoll_wait () from /lib64/libc.so.6 > ---Type to continue, or q to quit--- > # 1 0x00000000004b9559 in slapd_daemon_task (ptr=0x0) at daemon.c:2460 > # 2 0x000000370e8064a7 in start_thread () from /lib64/libpthread.so.0 > # 3 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > Thread 2 (process 12314): > # 0 0x000000370e80ab99 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > # 1 0x000000000059b0a3 in ldap_pvt_thread_cond_wait (cond=0xc538bc0, > mutex=0xc538b98) at thr_posix.c:277 > # 2 0x0000000000599b63 in ldap_int_thread_pool_wrapper (xpool=0xc538b90) > at tpool.c:672 > # 3 0x000000370e8064a7 in start_thread () from /lib64/libpthread.so.0 > # 4 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > Thread 1 (process 12313): > # 0 NdbTransaction::execute (this=0x15, > # aTypeOfExec=NdbTransaction::Rollback, > abortOption=NdbOperation::DefaultAbortOption, forceSend=0) > at NdbTransaction.cpp:278 > # 1 0x0000000000561195 in NdbTransaction::execute (this=0x15, > execType=Rollback, abortOption=DefaultAbortOption, force=0) > at /usr/include/mysql/storage/ndb/ndbapi/NdbTransaction.hpp:343 > # 2 0x0000000000575926 in ndb_back_add (op=0xc58c5d0, rs=0x4283ec00) > at add.cpp:336 > ---Type to continue, or q to quit--- > # 3 0x00000000004c6489 in fe_op_add (op=0xc58c5d0, rs=0x4283ec00) at > # add.c:334 4 0x00000000004c5e13 in do_add (op=0xc58c5d0, rs=0x4283ec00) > # at add.c:194 5 0x00000000004bd06a in connection_operation > # (ctx=0x4283ed50, > arg_v=0xc58c5d0) at connection.c:1123 > # 6 0x00000000004bd5ef in connection_read_thread (ctx=0x4283ed50, > # argv=0xd) > at connection.c:1259 > # 7 0x0000000000599c01 in ldap_int_thread_pool_wrapper (xpool=0xc538b90) > at tpool.c:685 > # 8 0x000000370e8064a7 in start_thread () from /lib64/libpthread.so.0 > # 9 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > (gdb) > On Tue, Dec 15, 2009 at 4:01 AM, Quanah Gibson-Mount quanah(a)zimbra.com> > wrote: > --On Saturday, December 12, 2009 5:48 PM +0000 quanah(a)zimbra.com wrote: > # 0=C2=A0 0x000000000066f891 in ?? () > (gdb) > So where's the thr apply all bt command inside gdb? You've just loaded > Please provide the backtrace as noted if you want this to be further > investigated. Thanks! > Again, after you run: > gdb > You then need to run: > thr apply all bt > To get a backtrace of all threads, and then submit that to the ITS. > --Quanah > -- > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration --001485f6da5ee30006047ac04fe7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Regards, -- afshin On Dec 15, 2009 11:58am, Quanah Gibson-M= ount <quanah(a)zimbra.com> wrote: > Afshin, > &gt= ; > > Copy openldap-its(a)openldap.org on all you replies s= o they go into the bug tracker, so that others can see them. > > > > --Quanah > > > > --On Tuesday, December 15, 2009 10:39 AM +0330 afshin afzali a.afzali= 2003(a)gmail.com> wrote: > > > > = > Hi Quanah, > > > > Appreciate your = help. Hope this be helpful. > > -- afshin > = > > > > > [root@dc1 libexec]# gdb ./= slapd core.12305 > > GNU gdb Fedora (6.8-37.el5) >= > Copyright (C) 2008 Free Software Foundation, Inc. > <br= />> License GPLv3+: GNU GPL version 3 or later > > htt= p://gnu.org/licenses/gpl.html> > > This is free softwar= e: you are free to change and redistribute it. > > There i= s NO WARRANTY, to the extent permitted by law.=A0 Type "show >= > copying" > > and "show warranty&quot= ; for details. > > This GDB was configured as "x86_64= -redhat-linux-gnu"... > > Reading symbols from /lib64= /libuuid.so.1...done. > > Loaded symbols for /lib64/libuui= d.so.1 > > Reading symbols from /lib64/librt.so.1...done.<= br />> > Loaded symbols for /lib64/librt.so.1 > &= gt; Reading symbols from /lib64/libcrypt.so.1...done. > > = Loaded symbols for /lib64/libcrypt.so.1 > > Reading symbol= s from /lib64/libnsl.so.1...done. > > Loaded symbols for /= lib64/libnsl.so.1 > > Reading symbols from /lib64/libm.so.= 6...done. > > Loaded symbols for /lib64/libm.so.6 &gt= ; > Reading symbols from /lib64/libpthread.so.0...done. > = > Loaded symbols for /lib64/libpthread.so.0 > > R= eading symbols from /usr/lib64/libstdc++.so.6...done. > > = Loaded symbols for /usr/lib64/libstdc++.so.6 > > Reading s= ymbols from /usr/lib64/libsasl2.so.2...done. > > Loaded sy= mbols for /usr/lib64/libsasl2.so.2 > > Reading symbols fro= m /lib64/libssl.so.6...done. > > Loaded symbols for /lib64= /libssl.so.6 > > Reading symbols from /lib64/libcrypto.so.= 6...done. > > Loaded symbols for /lib64/libcrypto.so.6 > > Reading symbols from /lib64/libresolv.so.2...done. &= gt; > Loaded symbols for /lib64/libresolv.so.2 > &gt= ; Reading symbols from /lib64/libgcc_s.so.1...done. > > Lo= aded symbols for /lib64/libgcc_s.so.1 > > Reading symbols = from /lib64/libc.so.6...done. > > Loaded symbols for /lib6= 4/libc.so.6 > > Reading symbols from /lib64/ld-linux-x86-6= 4.so.2...done. > > Loaded symbols for /lib64/ld-linux-x86-= 64.so.2 > > Reading symbols from /lib64/libdl.so.2...done.= > > Loaded symbols for /lib64/libdl.so.2 > = > Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done. > = > Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 > > Reading symbols from /usr/lib64/libkrb5.so.3...done. > > Loaded symbols for /usr/lib64/libkrb5.so.3 > > Readi= ng symbols from /lib64/libcom_err.so.2...done. > > Loaded = symbols for /lib64/libcom_err.so.2 > > Reading symbols fro= m /usr/lib64/libk5crypto.so.3...done. > > Loaded symbols f= or /usr/lib64/libk5crypto.so.3 > > Reading symbols from /u= sr/lib64/libz.so.1...done. > > Loaded symbols for /usr/lib= 64/libz.so.1 > > Reading symbols from /usr/lib64/libkrb5su= pport.so.0...done. > > Loaded symbols for /usr/lib64/libkr= b5support.so.0 > > Reading symbols from /lib64/libkeyutils= .so.1...done. > > Loaded symbols for /lib64/libkeyutils.so= .1 > > Reading symbols from /lib64/libselinux.so.1...done.= > > Loaded symbols for /lib64/libselinux.so.1 > <= br />> Reading symbols from /lib64/libsepol.so.1...done. > > Loaded symbols for /lib64/libsepol.so.1 > > Reading = symbols from /lib64/libnss_files.so.2...done. > > Loaded s= ymbols for /lib64/libnss_files.so.2 > > Reading symbols fr= om /usr/lib64/sasl2/libanonymous.so.2...done. > > Loaded s= ymbols for /usr/lib64/sasl2/libanonymous.so.2 > > Reading = symbols from /usr/lib64/sasl2/libsasldb.so.2...done. > > L= oaded symbols for /usr/lib64/sasl2/libsasldb.so.2 > > Read= ing symbols from /usr/lib64/sasl2/liblogin.so.2...done. > &gt= ; Loaded symbols for /usr/lib64/sasl2/liblogin.so.2 > > Re= ading symbols from /usr/lib64/sasl2/libplain.so.2...done. > &= gt; Loaded symbols for /usr/lib64/sasl2/libplain.so.2 > > = Core was generated by `./slapd -d5'. > > Program termi= nated with signal 11, Segmentation fault. > > [New process= 12313] > > [New process 12314] > > [New = process 12312] > > [New process 12311] > &gt= ; [New process 12310] > > [New process 12309] > <b= r />> [New process 12308] > > [New process 12307] = > > [New process 12305] > > # 0=A0 NdbTransact= ion::execute (this=3D0x15, > > # aTypeOfExec=3DNdbTransact= ion::Rollback, > > =A0=A0=A0 abortOption=3DNdbOperation::D= efaultAbortOption, forceSend=3D0) > > =A0=A0=A0 at NdbTran= saction.cpp:278 > > 278=A0=A0=A0=A0 NdbTransaction.cpp: No= such file or directory. > > =A0=A0=A0=A0=A0=A0=A0 in NdbT= ransaction.cpp > > (gdb) thr apply all bt > = > > > Thread 9 (process 12305): > > #= 0=A0 0x000000370e8077e5 in pthread_join () from /lib64/libpthread.so.0 > > # 1=A0 0x000000000059affb in ldap_pvt_thread_join (thread= =3D1107417408, > > =A0=A0=A0 thread_return=3D0x0) at thr_p= osix.c:197 > > # 2=A0 0x00000000004ba2a8 in slapd_daemon (= ) at daemon.c:2835 > > # 3=A0 0x000000000049bfad in main (= argc=3D2, argv=3D0x7fff78fd91e8) at > > # main.c:950 = > > Current language:=A0 auto; currently c++ > &g= t; > > Thread 8 (process 12307): > > # 0= =A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > &= gt; # 1=A0 0x000000000068a73b in my_sleep (m_seconds=3D) > &g= t; =A0=A0=A0 at my_sleep.c:34 > > # 2=A0 0x00000000006b3ff= 0 in TransporterFacade::threadMainReceive > > # (this=3D0x= c7a6530) > > =A0=A0=A0 at ../../../../storage/ndb/include/= portlib/NdbSleep.h:31 > > # 3=A0 0x00000000006b4049 in run= ReceiveResponse_C (me=3D0x0) > > =A0=A0=A0 at TransporterF= acade.cpp:564 > > # 4=A0 0x00000000006a35de in ndb_thread_= wrapper (_ss=3D0xc581620) at > > # NdbThread.c:147 5=A0 0x= 000000370e8064a7 in start_thread () from > > # /lib64/libp= thread.so.0 6=A0 0x000000370e0d3c2d in clone () from > > #= /lib64/libc.so.6 > > > > Thread 7 (proc= ess 12308): > > # 0=A0 0x000000370e0cced2 in select () fro= m /lib64/libc.so.6 > > # 1=A0 0x000000000068a73b in my_sle= ep (m_seconds=3D) > > ---Type to continue, or q to quit-= -- > > =A0=A0=A0 at my_sleep.c:34 > > # 2= =A0 0x00000000006b2d0f in TransporterFacade::threadMainSend > > # (this=3D0xc7a6530) > > =A0=A0=A0 at ../../../../st= orage/ndb/include/portlib/NdbSleep.h:31 > > # 3=A0 0x00000= 000006b2d89 in runSendRequest_C (me=3D0x0) > > =A0=A0=A0 a= t TransporterFacade.cpp:529 > > # 4=A0 0x00000000006a35de = in ndb_thread_wrapper (_ss=3D0xc588670) at > > # NdbThread= .c:147 5=A0 0x000000370e8064a7 in start_thread () from > >= # /lib64/libpthread.so.0 6=A0 0x000000370e0d3c2d in clone () from &gt= ; > # /lib64/libc.so.6 > > > > = Thread 6 (process 12309): > > # 0=A0 0x000000370e0cced2 in= select () from /lib64/libc.so.6 > > # 1=A0 0x000000000068= a73b in my_sleep (m_seconds=3D) > > =A0=A0=A0 at my_sleep.= c:34 > > # 2=A0 0x00000000006b9740 in ClusterMgr::threadMa= in (this=3D0xc7b8ce0) > > =A0=A0=A0 at ../../../../storage= /ndb/include/portlib/NdbSleep.h:31 > > # 3=A0 0x0000000000= 6b98d9 in runClusterMgr_C (me=3D0x0) at ClusterMgr.cpp:50 > &= gt; # 4=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0xc5888b0) at<br= />> > # NdbThread.c:147 5=A0 0x000000370e8064a7 in start_threa= d () from > > # /lib64/libpthread.so.0 6=A0 0x000000370e0d= 3c2d in clone () from > > # /lib64/libc.so.6 > <br= />> > > Thread 5 (process 12310): > &gt= ; # 0=A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > <b= r />> # 1=A0 0x000000000068a73b in my_sleep (m_seconds=3D) > <br= />> ---Type to continue, or q to quit--- > > =A0=A0= =A0 at my_sleep.c:34 > > # 2=A0 0x00000000006c8738 in Tran= sporterRegistry::start_clients_thread ( > > =A0=A0=A0 this= =3D0xc580c70) at > > ../../../../../storage/ndb/include/po= rtlib/NdbSleep.h:31 > > # 3=A0 0x00000000006c89e9 in run_s= tart_clients_C (me=3D0x0) > > =A0=A0=A0 at TransporterRegi= stry.cpp:1422 > > # 4=A0 0x00000000006a35de in ndb_thread_= wrapper (_ss=3D0xc588a40) at > > # NdbThread.c:147 5=A0 0x= 000000370e8064a7 in start_thread () from > > # /lib64/libp= thread.so.0 6=A0 0x000000370e0d3c2d in clone () from > > #= /lib64/libc.so.6 > > > > Thread 4 (proc= ess 12311): > > # 0=A0 0x000000370e0cced2 in select () fro= m /lib64/libc.so.6 > > # 1=A0 0x00000000006a82d6 in Socket= Server::doAccept (this=3D0xc7b8bd0) > > =A0=A0=A0 at Socke= tServer.cpp:189 > > # 2=A0 0x00000000006a8612 in SocketSer= ver::doRun (this=3D0xc7b8bd0) > > =A0=A0=A0 at SocketServe= r.cpp:279 > > # 3=A0 0x00000000006a8639 in socketServerThr= ead_C (_ss=3D0x1) > > =A0=A0=A0 at SocketServer.cpp:231<br= />> > # 4=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0= xc581710) at > > # NdbThread.c:147 5=A0 0x000000370e8064a7= in start_thread () from > > # /lib64/libpthread.so.0 6=A0= 0x000000370e0d3c2d in clone () from > > # /lib64/libc.so.= 6 > > > > Thread 3 (process 12312): > > # 0=A0 0x000000370e0d4018 in epoll_wait () from /lib64/lib= c.so.6 > > ---Type to continue, or q to quit--- &gt= ; > # 1=A0 0x00000000004b9559 in slapd_daemon_task (ptr=3D0x0) at = daemon.c:2460 > > # 2=A0 0x000000370e8064a7 in start_threa= d () from /lib64/libpthread.so.0 > > # 3=A0 0x000000370e0d= 3c2d in clone () from /lib64/libc.so.6 > > > > Thread 2 (process 12314): > > # 0=A0 0x000000370e80= ab99 in pthread_cond_wait@@GLIBC_2.3.2 () > > =A0=A0 from = /lib64/libpthread.so.0 > > # 1=A0 0x000000000059b0a3 in ld= ap_pvt_thread_cond_wait (cond=3D0xc538bc0, > > =A0=A0=A0 m= utex=3D0xc538b98) at thr_posix.c:277 > > # 2=A0 0x00000000= 00599b63 in ldap_int_thread_pool_wrapper (xpool=3D0xc538b90) > > =A0=A0=A0 at tpool.c:672 > > # 3=A0 0x000000370e806= 4a7 in start_thread () from /lib64/libpthread.so.0 > > # 4= =A0 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > &g= t; > > Thread 1 (process 12313): > > # 0= =A0 NdbTransaction::execute (this=3D0x15, > > # aTypeOfExe= c=3DNdbTransaction::Rollback, > > =A0=A0=A0 abortOption=3D= NdbOperation::DefaultAbortOption, forceSend=3D0) > > =A0= =A0=A0 at NdbTransaction.cpp:278 > > # 1=A0 0x000000000056= 1195 in NdbTransaction::execute (this=3D0x15, > > =A0=A0= =A0 execType=3DRollback, abortOption=3DDefaultAbortOption, force=3D0) = > > =A0=A0=A0 at /usr/include/mysql/storage/ndb/ndbapi/NdbTrans= action.hpp:343 > > # 2=A0 0x0000000000575926 in ndb_back_a= dd (op=3D0xc58c5d0, rs=3D0x4283ec00) > > =A0=A0=A0 at add.= cpp:336 > > ---Type to continue, or q to quit--- &g= t; > # 3=A0 0x00000000004c6489 in fe_op_add (op=3D0xc58c5d0, rs=3D= 0x4283ec00) at > > # add.c:334 4=A0 0x00000000004c5e13 in = do_add (op=3D0xc58c5d0, rs=3D0x4283ec00) > > # at add.c:19= 4 5=A0 0x00000000004bd06a in connection_operation > > # (c= tx=3D0x4283ed50, > > =A0=A0=A0 arg_v=3D0xc58c5d0) at conne= ction.c:1123 > > # 6=A0 0x00000000004bd5ef in connection_r= ead_thread (ctx=3D0x4283ed50, > > # argv=3D0xd) > = > =A0=A0=A0 at connection.c:1259 > > # 7=A0 0x000= 0000000599c01 in ldap_int_thread_pool_wrapper (xpool=3D0xc538b90) >= > =A0=A0=A0 at tpool.c:685 > > # 8=A0 0x00000037= 0e8064a7 in start_thread () from /lib64/libpthread.so.0 > &gt= ; # 9=A0 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > <br= />> (gdb) > > > > > &= gt; > > > > On Tue, Dec 15, 2009 at 4:0= 1 AM, Quanah Gibson-Mount quanah(a)zimbra.com> > > wrote:= > > > > --On Saturday, December 12, 200= 9 5:48 PM +0000 quanah(a)zimbra.com wrote: > > > <b= r />> > > > > > > = # 0=3DC2=3DA0 0x000000000066f891 in ?? () > > (gdb) &= gt; > > > > > > > So where's the thr apply all bt command inside gdb? =A0You've= just loaded > > > > > &g= t; Please provide the backtrace as noted if you want this to be further > > investigated. =A0Thanks! > > > = > Again, after you run: > > > >= gdb > > > > You then need to run: > > > > thr apply all bt > &g= t; > > To get a backtrace of all threads, and then submit= that to the ITS. > > > > > <br= />> > > > > --Quanah > > > > > > -- > > = > > Quanah Gibson-Mount > > Principal So= ftware Engineer > > Zimbra, Inc > > -----= --------------- > > Zimbra :: =A0the leader in open source= messaging and collaboration > > > > <br= />> > > > > > > <= br />> > -- > > > > Quanah G= ibson-Mount > > Principal Software Engineer > > Zimbra, Inc > > -------------------- > > Zimbra :: =A0the leader in open source messaging and collaboration<b= r />> --001485f6da5ee30006047ac04fe7--

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 15 Dec '09

15 Dec '09

Afshin, Copy openldap-its(a)openldap.org on all you replies so they go into the bug=20 tracker, so that others can see them. --Quanah --On Tuesday, December 15, 2009 10:39 AM +0330 afshin afzali=20 <a.afzali2003(a)gmail.com> wrote: > Hi Quanah, > > Appreciate your help. Hope this be helpful. > -- afshin > > > [root@dc1 libexec]# gdb ./slapd core.12305 > GNU gdb Fedora (6.8-37.el5) > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law.=C2=A0 Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu"... > Reading symbols from /lib64/libuuid.so.1...done. > Loaded symbols for /lib64/libuuid.so.1 > Reading symbols from /lib64/librt.so.1...done. > Loaded symbols for /lib64/librt.so.1 > Reading symbols from /lib64/libcrypt.so.1...done. > Loaded symbols for /lib64/libcrypt.so.1 > Reading symbols from /lib64/libnsl.so.1...done. > Loaded symbols for /lib64/libnsl.so.1 > Reading symbols from /lib64/libm.so.6...done. > Loaded symbols for /lib64/libm.so.6 > Reading symbols from /lib64/libpthread.so.0...done. > Loaded symbols for /lib64/libpthread.so.0 > Reading symbols from /usr/lib64/libstdc++.so.6...done. > Loaded symbols for /usr/lib64/libstdc++.so.6 > Reading symbols from /usr/lib64/libsasl2.so.2...done. > Loaded symbols for /usr/lib64/libsasl2.so.2 > Reading symbols from /lib64/libssl.so.6...done. > Loaded symbols for /lib64/libssl.so.6 > Reading symbols from /lib64/libcrypto.so.6...done. > Loaded symbols for /lib64/libcrypto.so.6 > Reading symbols from /lib64/libresolv.so.2...done. > Loaded symbols for /lib64/libresolv.so.2 > Reading symbols from /lib64/libgcc_s.so.1...done. > Loaded symbols for /lib64/libgcc_s.so.1 > Reading symbols from /lib64/libc.so.6...done. > Loaded symbols for /lib64/libc.so.6 > Reading symbols from /lib64/ld-linux-x86-64.so.2...done. > Loaded symbols for /lib64/ld-linux-x86-64.so.2 > Reading symbols from /lib64/libdl.so.2...done. > Loaded symbols for /lib64/libdl.so.2 > Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done. > Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 > Reading symbols from /usr/lib64/libkrb5.so.3...done. > Loaded symbols for /usr/lib64/libkrb5.so.3 > Reading symbols from /lib64/libcom_err.so.2...done. > Loaded symbols for /lib64/libcom_err.so.2 > Reading symbols from /usr/lib64/libk5crypto.so.3...done. > Loaded symbols for /usr/lib64/libk5crypto.so.3 > Reading symbols from /usr/lib64/libz.so.1...done. > Loaded symbols for /usr/lib64/libz.so.1 > Reading symbols from /usr/lib64/libkrb5support.so.0...done. > Loaded symbols for /usr/lib64/libkrb5support.so.0 > Reading symbols from /lib64/libkeyutils.so.1...done. > Loaded symbols for /lib64/libkeyutils.so.1 > Reading symbols from /lib64/libselinux.so.1...done. > Loaded symbols for /lib64/libselinux.so.1 > Reading symbols from /lib64/libsepol.so.1...done. > Loaded symbols for /lib64/libsepol.so.1 > Reading symbols from /lib64/libnss_files.so.2...done. > Loaded symbols for /lib64/libnss_files.so.2 > Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...done. > Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2 > Reading symbols from /usr/lib64/sasl2/libsasldb.so.2...done. > Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2 > Reading symbols from /usr/lib64/sasl2/liblogin.so.2...done. > Loaded symbols for /usr/lib64/sasl2/liblogin.so.2 > Reading symbols from /usr/lib64/sasl2/libplain.so.2...done. > Loaded symbols for /usr/lib64/sasl2/libplain.so.2 > Core was generated by `./slapd -d5'. > Program terminated with signal 11, Segmentation fault. > [New process 12313] > [New process 12314] > [New process 12312] > [New process 12311] > [New process 12310] > [New process 12309] > [New process 12308] > [New process 12307] > [New process 12305] ># 0=C2=A0 NdbTransaction::execute (this=3D0x15, ># aTypeOfExec=3DNdbTransaction::Rollback, > =C2=A0=C2=A0=C2=A0 abortOption=3DNdbOperation::DefaultAbortOption, = forceSend=3D0) > =C2=A0=C2=A0=C2=A0 at NdbTransaction.cpp:278 > 278=C2=A0=C2=A0=C2=A0=C2=A0 NdbTransaction.cpp: No such file or = directory. > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in NdbTransaction.cpp > (gdb) thr apply all bt > > Thread 9 (process 12305): ># 0=C2=A0 0x000000370e8077e5 in pthread_join () from = /lib64/libpthread.so.0 ># 1=C2=A0 0x000000000059affb in ldap_pvt_thread_join (thread=3D1107417408, > =C2=A0=C2=A0=C2=A0 thread_return=3D0x0) at thr_posix.c:197 ># 2=C2=A0 0x00000000004ba2a8 in slapd_daemon () at daemon.c:2835 ># 3=C2=A0 0x000000000049bfad in main (argc=3D2, argv=3D0x7fff78fd91e8) at ># main.c:950 > Current language:=C2=A0 auto; currently c++ > > Thread 8 (process 12307): ># 0=C2=A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 ># 1=C2=A0 0x000000000068a73b in my_sleep (m_seconds=3D<value optimized = out>) > =C2=A0=C2=A0=C2=A0 at my_sleep.c:34 ># 2=C2=A0 0x00000000006b3ff0 in TransporterFacade::threadMainReceive ># (this=3D0xc7a6530) > =C2=A0=C2=A0=C2=A0 at = ../../../../storage/ndb/include/portlib/NdbSleep.h:31 ># 3=C2=A0 0x00000000006b4049 in runReceiveResponse_C (me=3D0x0) > =C2=A0=C2=A0=C2=A0 at TransporterFacade.cpp:564 ># 4=C2=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0xc581620) at ># NdbThread.c:147 5=C2=A0 0x000000370e8064a7 in start_thread () from ># /lib64/libpthread.so.0 6=C2=A0 0x000000370e0d3c2d in clone () from ># /lib64/libc.so.6 > > Thread 7 (process 12308): ># 0=C2=A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 ># 1=C2=A0 0x000000000068a73b in my_sleep (m_seconds=3D<value optimized = out>) > ---Type <return> to continue, or q <return> to quit--- > =C2=A0=C2=A0=C2=A0 at my_sleep.c:34 ># 2=C2=A0 0x00000000006b2d0f in TransporterFacade::threadMainSend ># (this=3D0xc7a6530) > =C2=A0=C2=A0=C2=A0 at = ../../../../storage/ndb/include/portlib/NdbSleep.h:31 ># 3=C2=A0 0x00000000006b2d89 in runSendRequest_C (me=3D0x0) > =C2=A0=C2=A0=C2=A0 at TransporterFacade.cpp:529 ># 4=C2=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0xc588670) at ># NdbThread.c:147 5=C2=A0 0x000000370e8064a7 in start_thread () from ># /lib64/libpthread.so.0 6=C2=A0 0x000000370e0d3c2d in clone () from ># /lib64/libc.so.6 > > Thread 6 (process 12309): ># 0=C2=A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 ># 1=C2=A0 0x000000000068a73b in my_sleep (m_seconds=3D<value optimized = out>) > =C2=A0=C2=A0=C2=A0 at my_sleep.c:34 ># 2=C2=A0 0x00000000006b9740 in ClusterMgr::threadMain (this=3D0xc7b8ce0) > =C2=A0=C2=A0=C2=A0 at = ../../../../storage/ndb/include/portlib/NdbSleep.h:31 ># 3=C2=A0 0x00000000006b98d9 in runClusterMgr_C (me=3D0x0) at = ClusterMgr.cpp:50 ># 4=C2=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0xc5888b0) at ># NdbThread.c:147 5=C2=A0 0x000000370e8064a7 in start_thread () from ># /lib64/libpthread.so.0 6=C2=A0 0x000000370e0d3c2d in clone () from ># /lib64/libc.so.6 > > Thread 5 (process 12310): ># 0=C2=A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 ># 1=C2=A0 0x000000000068a73b in my_sleep (m_seconds=3D<value optimized = out>) > ---Type <return> to continue, or q <return> to quit--- > =C2=A0=C2=A0=C2=A0 at my_sleep.c:34 ># 2=C2=A0 0x00000000006c8738 in TransporterRegistry::start_clients_thread = ( > =C2=A0=C2=A0=C2=A0 this=3D0xc580c70) at > ../../../../../storage/ndb/include/portlib/NdbSleep.h:31 ># 3=C2=A0 0x00000000006c89e9 in run_start_clients_C (me=3D0x0) > =C2=A0=C2=A0=C2=A0 at TransporterRegistry.cpp:1422 ># 4=C2=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0xc588a40) at ># NdbThread.c:147 5=C2=A0 0x000000370e8064a7 in start_thread () from ># /lib64/libpthread.so.0 6=C2=A0 0x000000370e0d3c2d in clone () from ># /lib64/libc.so.6 > > Thread 4 (process 12311): ># 0=C2=A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 ># 1=C2=A0 0x00000000006a82d6 in SocketServer::doAccept (this=3D0xc7b8bd0) > =C2=A0=C2=A0=C2=A0 at SocketServer.cpp:189 ># 2=C2=A0 0x00000000006a8612 in SocketServer::doRun (this=3D0xc7b8bd0) > =C2=A0=C2=A0=C2=A0 at SocketServer.cpp:279 ># 3=C2=A0 0x00000000006a8639 in socketServerThread_C (_ss=3D0x1) > =C2=A0=C2=A0=C2=A0 at SocketServer.cpp:231 ># 4=C2=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0xc581710) at ># NdbThread.c:147 5=C2=A0 0x000000370e8064a7 in start_thread () from ># /lib64/libpthread.so.0 6=C2=A0 0x000000370e0d3c2d in clone () from ># /lib64/libc.so.6 > > Thread 3 (process 12312): ># 0=C2=A0 0x000000370e0d4018 in epoll_wait () from /lib64/libc.so.6 > ---Type <return> to continue, or q <return> to quit--- ># 1=C2=A0 0x00000000004b9559 in slapd_daemon_task (ptr=3D0x0) at = daemon.c:2460 ># 2=C2=A0 0x000000370e8064a7 in start_thread () from = /lib64/libpthread.so.0 ># 3=C2=A0 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > > Thread 2 (process 12314): ># 0=C2=A0 0x000000370e80ab99 in pthread_cond_wait@@GLIBC_2.3.2 () > =C2=A0=C2=A0 from /lib64/libpthread.so.0 ># 1=C2=A0 0x000000000059b0a3 in ldap_pvt_thread_cond_wait = (cond=3D0xc538bc0, > =C2=A0=C2=A0=C2=A0 mutex=3D0xc538b98) at thr_posix.c:277 ># 2=C2=A0 0x0000000000599b63 in ldap_int_thread_pool_wrapper = (xpool=3D0xc538b90) > =C2=A0=C2=A0=C2=A0 at tpool.c:672 ># 3=C2=A0 0x000000370e8064a7 in start_thread () from = /lib64/libpthread.so.0 ># 4=C2=A0 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > > Thread 1 (process 12313): ># 0=C2=A0 NdbTransaction::execute (this=3D0x15, ># aTypeOfExec=3DNdbTransaction::Rollback, > =C2=A0=C2=A0=C2=A0 abortOption=3DNdbOperation::DefaultAbortOption, = forceSend=3D0) > =C2=A0=C2=A0=C2=A0 at NdbTransaction.cpp:278 ># 1=C2=A0 0x0000000000561195 in NdbTransaction::execute (this=3D0x15, > =C2=A0=C2=A0=C2=A0 execType=3DRollback, abortOption=3DDefaultAbortOption, = force=3D0) > =C2=A0=C2=A0=C2=A0 at = /usr/include/mysql/storage/ndb/ndbapi/NdbTransaction.hpp:343 ># 2=C2=A0 0x0000000000575926 in ndb_back_add (op=3D0xc58c5d0, = rs=3D0x4283ec00) > =C2=A0=C2=A0=C2=A0 at add.cpp:336 > ---Type <return> to continue, or q <return> to quit--- ># 3=C2=A0 0x00000000004c6489 in fe_op_add (op=3D0xc58c5d0, = rs=3D0x4283ec00) at ># add.c:334 4=C2=A0 0x00000000004c5e13 in do_add (op=3D0xc58c5d0, = rs=3D0x4283ec00) ># at add.c:194 5=C2=A0 0x00000000004bd06a in connection_operation ># (ctx=3D0x4283ed50, > =C2=A0=C2=A0=C2=A0 arg_v=3D0xc58c5d0) at connection.c:1123 ># 6=C2=A0 0x00000000004bd5ef in connection_read_thread (ctx=3D0x4283ed50, ># argv=3D0xd) > =C2=A0=C2=A0=C2=A0 at connection.c:1259 ># 7=C2=A0 0x0000000000599c01 in ldap_int_thread_pool_wrapper = (xpool=3D0xc538b90) > =C2=A0=C2=A0=C2=A0 at tpool.c:685 ># 8=C2=A0 0x000000370e8064a7 in start_thread () from = /lib64/libpthread.so.0 ># 9=C2=A0 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > (gdb) > > > > > On Tue, Dec 15, 2009 at 4:01 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> > wrote: > > --On Saturday, December 12, 2009 5:48 PM +0000 quanah(a)zimbra.com wrote: > > > > ># 0=3DC2=3DA0 0x000000000066f891 in ?? () > (gdb) > > > > So where's the thr apply all bt command inside gdb? =C2=A0You've just = loaded > > > Please provide the backtrace as noted if you want this to be further > investigated. =C2=A0Thanks! > > Again, after you run: > > gdb </slapd> <core> > > You then need to run: > > thr apply all bt > > To get a backtrace of all threads, and then submit that to the ITS. > > > > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: =C2=A0the leader in open source messaging and collaboration > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs