openldap-bugs

openldap-bugs@openldap.org

1 participants
20765 discussions

Re: (ITS#4699) snacc-2.3.3beta doesn't compile
by Kurt＠OpenLDAP.org 05 Oct '06

05 Oct '06

I suggest that anyone wanting to toy with LDAP component matching in OpenLDAP Software use HEAD... the feature needs work. At 02:18 PM 10/5/2006, dieter(a)dkluenter.de wrote: >Full_Name: Dieter Kluenter >Version: openldap-snacc-2.3.3beta Not sure why you didn't try 2.3.6, but regardless, see above. Kurt

1 0

(ITS#4699) snacc-2.3.3beta doesn't compile
by dieter＠dkluenter.de 05 Oct '06

05 Oct '06

Full_Name: Dieter Kluenter Version: openldap-snacc-2.3.3beta OS: linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.210.55) Hi, This are the errors from my attempt to compile snacc /usr/include/c++/3.3.5/backward/backward_warning.h:32:2: Warnung: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated. vdatest.cpp: In function `void test_timingDoTestPrint(long int, long int, int, long int)': vdatest.cpp:1048: Warnung: int Format, anderer Typ Argument (Argument 4) vdatest.cpp: In function `void AsnIntTest()': vdatest.cpp:1283: error: no matching function for call to `SNACC::AsnInt:: getPadded(unsigned char*&, unsigned int&, int)' ../../c++-lib/inc/asn-incl.h:645: error: candidates are: void SNACC::AsnInt::getPadded(unsigned char*&, size_t&, long unsigned int) const vdatest.cpp:1335: error: no matching function for call to `SNACC::AsnInt:: getPadded(unsigned char*&, unsigned int&, int)' ../../c++-lib/inc/asn-incl.h:645: error: candidates are: void SNACC::AsnInt::getPadded(unsigned char*&, size_t&, long unsigned int) const make[3]: *** [vdatest.o] Fehler 1 make[3]: Leaving directory `/work/openldap-snacc-2.3.3beta/c++-examples/src' make[2]: *** [all] Fehler 2 make[2]: Leaving directory `/work/openldap-snacc-2.3.3beta/c++-examples/src' make[1]: *** [all] Fehler 2 make[1]: Leaving directory `/work/openldap-snacc-2.3.3beta/c++-examples' make: *** [all] Fehler 2 -Dieter

1 0

Re: authz-regexp matches twice on same dse (ITS#4698)
by ap＠d-dt.de 05 Oct '06

05 Oct '06

Pierangelo Masarati wrote: > I don't see an error in OpenLDAP software here. authz regexp matching is > designed to succeed only if the identity is univoquely resolved to exactly one > DN. I'm afraid but I cannot even imagine how slapd could decide to pick one out > of many DNs when authenticating a user; I guess noone else can. > > p. > Matched dn's are unique, as they describing the same Entry: dn: uid=works,dc=example,dc=org objectClass: extensibleObject uid: works dn: cn=worksalso,dc=example,dc=org objectClass: extensibleObject cn: worksalso dn: uid=fails,dc=example,dc=org objectClass: extensibleObject uid: fails cn: fails "(|(cn=works)(uid=works))" and "(|(cn=worksalso)(uid=worksalso))" matching either attribute, whereas "(|(cn=works)(uid=works))" matches twice, but describes the same object. ldapsearching for "(|(cn=fails)(uid=fails))" will also return only the one and unique entry "uid=fails,dc=example,dc=org" A --

1 0

Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by tim＠dcs.qmul.ac.uk 05 Oct '06

05 Oct '06

Howard Chu wrote: > tim(a)dcs.qmul.ac.uk wrote: >> Full_Name: Tim Kay >> Version: OS: Linux (Fedora core 5 RPM) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (138.37.95.144) >> >> >> Modifying a DN on the syncrepl provider fails to propogate to the >> consumer. The >> provider "sends" a valid modify but the consumer, having received the >> modify >> request walks the tree, returns the parent DN to the entry, >> determines that >> write access is permitted and the iterates, at this point >> newSuperior->bv_val is >> set to "*" !? bdb_dn2entry is now searching for "�UUU" which >> looks like >> some unicode screw up. > > Try the patch in CVS slapd/syncrepl.c 1.272 -> 1.273 > That appears to have nailed it. Thank you very much and bug closed I think. Seven hours between bug report and patch release is something to shout from the rooftops too. Best, Tim -- Tim Kay Systems Programmer Department of Computer Science Queen Mary, University of London. Tel: +44 (0) 207 882 7521 Fax: +44 (0) 208 980 6533

1 0

(ITS#4698) authz-regexp matches twice on same dse
by adampordzik＠gmx.de 05 Oct '06

05 Oct '06

Full_Name: Adam pordzik Version: 2.3.27 OS: FreeBSD 5-STABLE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.171.35.164) authz-regexp uid=([^,]+),cn=[^,]+,cn=auth ldap:///dc=example,dc=org??sub?(|(cn=$1)(uid=$1)) Below dc=example,dc=org there is a DSE with same value for uid and cn, which I can't bind to with SASL. Since Authentication against this entry works after its cn-attributes rename (or deletition of same-valued cn) works, as also agianst other found entries, I assueme this is due to twice matching the same entry.

1 0

Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by hyc＠symas.com 04 Oct '06

04 Oct '06

tim(a)dcs.qmul.ac.uk wrote: > Full_Name: Tim Kay > Version: > OS: Linux (Fedora core 5 RPM) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (138.37.95.144) > > > Modifying a DN on the syncrepl provider fails to propogate to the consumer. The > provider "sends" a valid modify but the consumer, having received the modify > request walks the tree, returns the parent DN to the entry, determines that > write access is permitted and the iterates, at this point newSuperior->bv_val is > set to "*" !? bdb_dn2entry is now searching for "�UUU" which looks like > some unicode screw up. Try the patch in CVS slapd/syncrepl.c 1.272 -> 1.273 -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4697) core dump from acl.c regex
by quanah＠stanford.edu 04 Oct '06

04 Oct '06

--On Wednesday, October 04, 2006 8:21 PM +0000 quanah(a)stanford.edu wrote: The acl bits of "a" show: (gdb) thread 1 [Switching to thread 1 (process 28461)]#0 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6 (gdb) frame 7 #7 0x0000000000446058 in slap_access_allowed (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x42e7d408) at acl.c:874 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) (gdb) print *a $1 = {acl_filter = 0x0, acl_dn_style = ACL_STYLE_CHILDREN, acl_dn_re = {buffer = 0x0, allocated = 0, used = 0, syntax = 0, fastmap = 0x0, translate = 0x0, re_nsub = 0, can_be_null = 0, regs_allocated = 0, fastmap_accurate = 0, no_sub = 0, not_bol = 0, not_eol = 0, newline_anchor = 0}, acl_dn_pat = {bv_len = 18, bv_val = 0x2b9d6e54e900 "dc=stanford,dc=edu"}, acl_attrs = 0x2b9d6e4c0080, acl_attrval_mr = 0x0, acl_attrval_style = ACL_STYLE_REGEX, acl_attrval_re = {buffer = 0x0, allocated = 0, used = 0, syntax = 0, fastmap = 0x0, translate = 0x0, re_nsub = 0, can_be_null = 0, regs_allocated = 0, fastmap_accurate = 0, no_sub = 0, not_bol = 0, not_eol = 0, newline_anchor = 0}, acl_attrval = {bv_len = 0, bv_val = 0x0}, acl_access = 0x2b9d6e969ae0, acl_next = 0x2b9d6e9455c0} It seems we should have never gotten to this section of the code: (gdb) l 855 /* Is this ACL only for a specific value? */ 856 if ( a->acl_attrval.bv_len ) { 857 if ( val == NULL ) { 858 continue; 859 } 860 861 if( state && !( state->as_recorded & ACL_STATE_RECORDED_VD )) { 862 state->as_recorded |= ACL_STATE_RECORDED_VD; 863 state->as_vd_acl = a; 864 state->as_vd_acl_count = *count; 865 state->as_vd_access = a->acl_access; 866 state->as_vd_access_count = 1; 867 ACL_INVALIDATE( state->as_vd_acl_mask ); 868 } 869 870 if ( a->acl_attrval_style == ACL_STYLE_REGEX ) { 871 Debug( LDAP_DEBUG_ACL, 872 "acl_get: valpat %s\n", 873 a->acl_attrval.bv_val, 0, 0 ); 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) Since a->acl_attrval.bv_len is 0. At the moment, Howard and I blame the compiler (gcc 3.4) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by tim＠dcs.qmul.ac.uk 04 Oct '06

04 Oct '06

Quanah Gibson-Mount wrote: > > > --On Wednesday, October 04, 2006 6:06 PM +0000 tim(a)dcs.qmul.ac.uk wrote: > >> Full_Name: Tim Kay >> Version: >> OS: Linux (Fedora core 5 RPM) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (138.37.95.144) >> >> >> Modifying a DN on the syncrepl provider fails to propogate to the >> consumer. The provider "sends" a valid modify but the consumer, having >> received the modify request walks the tree, returns the parent DN to the >> entry, determines that write access is permitted and the iterates, at >> this point newSuperior->bv_val is set to "*" !? bdb_dn2entry is now >> searching for "�UUU" which looks like some unicode screw up. > > You didn't provide an OpenLDAP version. I'll note that if you intend to > use syncrepl, use OpenLDAP 2.3.27 (or later). > > --Quanah > Sorry Quanah (and everyone else), The identical problem is happening in both 2.3.27 and 2.3.19 with both the bdb and ldbm back ends. Tim > > -- > Quanah Gibson-Mount > Principal Software Developer > ITS/Shared Application Services > Stanford University > GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4697) core dump from acl.c regex
by quanah＠stanford.edu 04 Oct '06

04 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.27/HEAD OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) The following core happened today on one of my replicas: Core was generated by `/usr/local/lib/slapd -h ldap:///'. Program terminated with signal 11, Segmentation fault. (gdb) info threads 10 process 28453 0x00002b9d6da82e2c in pthread_join () from /lib/libpthread.so.0 9 process 28455 0x00002b9d6dc62b2c in epoll_wait () from /lib/libc.so.6 8 process 28456 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 7 process 28457 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 6 process 28458 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 5 process 28459 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 4 process 28462 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 3 process 28463 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 2 process 28464 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 * 1 process 28461 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6 (gdb) thread 10 [Switching to thread 10 (process 28453)]#0 0x00002b9d6da82e2c in pthread_join () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da82e2c in pthread_join () from /lib/libpthread.so.0 #1 0x0000000000425d41 in slapd_daemon () at daemon.c:2261 #2 0x0000000000416254 in main (argc=3, argv=0x7fffffd3c4c8) at main.c:854 (gdb) thread 9 [Switching to thread 9 (process 28455)]#0 0x00002b9d6dc62b2c in epoll_wait () from /lib/libc.so.6 (gdb) bt #0 0x00002b9d6dc62b2c in epoll_wait () from /lib/libc.so.6 #1 0x0000000000425389 in slapd_daemon_task (ptr=0x6) at daemon.c:1859 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 8 [Switching to thread 8 (process 28456)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 (gdb) thread 7 [Switching to thread 7 (process 28457)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 6 [Switching to thread 6 (process 28458)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 (gdb) thread 5 [Switching to thread 5 (process 28459)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 4 [Switching to thread 4 (process 28462)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 (gdb) thread 3 [Switching to thread 3 (process 28463)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 2 [Switching to thread 2 (process 28464)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 1 [Switching to thread 1 (process 28461)]#0 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6 (gdb) bt #0 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6 #1 0x00002b9d6dc4dd22 in re_exec () from /lib/libc.so.6 #2 0x00002b9d6dc4b70b in re_exec () from /lib/libc.so.6 #3 0x00002b9d6dc49d83 in re_exec () from /lib/libc.so.6 #4 0x00002b9d6dc48526 in re_exec () from /lib/libc.so.6 #5 0x00002b9d6dc47e83 in re_exec () from /lib/libc.so.6 #6 0x00002b9d6dc474a6 in regexec () from /lib/libc.so.6 #7 0x0000000000446058 in slap_access_allowed (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x42e7d408) at acl.c:874 #8 0x0000000000448521 in fe_access_allowed (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x0) at acl.c:318 #9 0x0000000000443df3 in access_allowed_mask (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x0) at acl.c:429 #10 0x0000000000436e1b in slap_send_search_entry (op=0x2aaaafd40080, rs=0x42ffeeb0) at result.c:894 #11 0x00002b9d6f7342dc in hdb_search (op=0x2aaaafd40080, rs=0x42ffeeb0) at search.c:878 #12 0x000000000042a30a in fe_op_search (op=0x2aaaafd40080, rs=0x42ffeeb0) at search.c:355 #13 0x0000000000429c45 in do_search (op=0x2aaaafd40080, rs=0x42ffeeb0) at search.c:217 #14 0x000000000042837d in connection_operation (ctx=0x42fff020, arg_v=0x2aaaafd40080) at connection.c:1100 #15 0x0000000000428a33 in connection_read_thread (ctx=0x42fff020, argv=0x0) at connection.c:1227 #16 0x00002b9d6d03f522 in ldap_int_thread_pool_wrapper (xpool=0x1) at tpool.c:478 #17 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #18 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 Given that all threads except thread 1 appear to be in the same spot, I'm guessing the problem is in thread 1. Code is: (gdb) frame 7 #7 0x0000000000446058 in slap_access_allowed (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x42e7d408) at acl.c:874 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) (gdb) l 869 870 if ( a->acl_attrval_style == ACL_STYLE_REGEX ) { 871 Debug( LDAP_DEBUG_ACL, 872 "acl_get: valpat %s\n", 873 a->acl_attrval.bv_val, 0, 0 ); 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) 875 { 876 continue; 877 } 878 --Quanah

1 0

(ITS#4696) Assert core in connection.c
by quanah＠stanford.edu 04 Oct '06

04 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.27/HEAD OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) The following core occurred on one of my replica systems today: (gdb) info threads 10 process 22650 0x00002b41c03a1e2c in pthread_join () from /lib/libpthread.so.0 9 process 22652 0x00002b41c0581b2c in epoll_wait () from /lib/libc.so.6 8 process 22653 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 7 process 22654 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 6 process 22655 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 5 process 22663 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 4 process 22706 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 3 process 22707 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 2 process 22708 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 * 1 process 22705 0x00002b41c04de545 in raise () from /lib/libc.so.6 In particular: [Switching to thread 1 (process 22705)]#3 0x00000000004271c5 in connection_close (c=0x2b42c5088358) at connection.c:655 655 assert( c->c_writewaiter == 0); (gdb) bt #0 0x00002b41c04de545 in raise () from /lib/libc.so.6 #1 0x00002b41c04dfcce in abort () from /lib/libc.so.6 #2 0x00002b41c04d8362 in __assert_fail () from /lib/libc.so.6 #3 0x00000000004271c5 in connection_close (c=0x2b42c5088358) at connection.c:655 #4 0x0000000000428a6c in connection_read_thread (ctx=0x42fff020, argv=0x68) at connection.c:1391 #5 0x00002b41bf95e522 in ldap_int_thread_pool_wrapper (xpool=0x587a) at tpool.c:478 #6 0x00002b41bf66fc93 in startMeUp () from /usr/local/lib/libhoard.so #7 0x00002b41c03a0b55 in start_thread () from /lib/libpthread.so.0 #8 0x00002b41c05817f0 in clone () from /lib/libc.so.6 (gdb) frame 3 #3 0x00000000004271c5 in connection_close (c=0x2b42c5088358) at connection.c:655 655 assert( c->c_writewaiter == 0); (gdb) l 650 assert( connections != NULL ); 651 assert( c != NULL ); 652 assert( c->c_struct_state != SLAP_C_UNUSED ); 653 assert( c->c_conn_state != SLAP_C_INVALID ); 654 assert( LDAP_STAILQ_EMPTY(&c->c_ops) ); 655 assert( c->c_writewaiter == 0); 656 657 /* only for stats (print -1 as "%lu" may give unexpected results ;) */ 658 connid = c->c_connid; 659 close_reason = c->c_close_reason; --Quanah

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs