openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5646) Unable to make the openldap-2.4.11 in fedora9
by snkg24＠gmail.com 07 Aug '08

07 Aug '08

Full_Name: Nar Version: openldap-2.4.11 OS: Fedora 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.93.52.62) Hi all, I am unable to install the openldap using configure. The following error appearing after inputting the command "make". Please provide the solution. ----------- [root@eltserv openldap-2.4.11]# make Making all in /root/Download/openldap-2.4.11 Entering subdirectory include make[1]: Entering directory `/root/Download/openldap-2.4.11/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/root/Download/openldap-2.4.11/include' Entering subdirectory libraries make[1]: Entering directory `/root/Download/openldap-2.4.11/libraries' Making all in /root/Download/openldap-2.4.11/libraries Entering subdirectory liblutil make[2]: Entering directory `/root/Download/openldap-2.4.11/libraries/liblutil' rm -f version.c ../../build/mkversion -v "2.4.11" liblutil.a > version.c cc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB/include -c -o utils.o utils.c cc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB/include -c -o fetch.o fetch.c cc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB/include -c -o getpeereid.o getpeereid.c getpeereid.c: In function lutil_getpeereid: getpeereid.c:65: error: storage size of peercred isnt known make[2]: *** [getpeereid.o] Error 1 make[2]: Leaving directory `/root/Download/openldap-2.4.11/libraries/liblutil' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/root/Download/openldap-2.4.11/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#5642) Double free on exit, when specific attributetype is defined
by hyc＠symas.com 06 Aug '08

06 Aug '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >>> attributetype ( 278.1.3.6.1 NAME 'requireClass' SUP objectClass ) >> This is now fixed in HEAD. > > Slapd should to refuse to start with a bogus OID like that. > OIDs start with components<0-1>.<0-39> or 2.<any>. > > The LDAP standard doesn't seem to mention this, but RFC 4517 does defer > to X.680 (the ASN.1 spec), which since 1998 has deferred to X.660 - > which I don't have:-( Anyway, my reference is John Larmouth's _ASN.1 > Complete_. And it can be inferred from the BER encoding of the OBJECT > IDENTIFIER type. > Feel free to patch it. The fix I committed was simply to the double-free for any attributeType that inherits from objectClass... -- -- 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#5644) make test000 core dumps
by michael＠stroeder.com 06 Aug '08

06 Aug '08

Ralf Haferkamp wrote: > On Dienstag, 5. August 2008, michael(a)stroeder.com wrote: >> [..] >> slapd starting >> daemon: listen(ldap://localhost:9011/, 5) failed errno=3D98 (Address >> alre= ady in use) >> lt-slapd shutdown: initiated >> =3D=3D=3D=3D> bdb_cache_release_all >> lt-slapd destroy: freeing system resources. >> slapd stopped. >> >> --------------000504090501070603080100-- > This might just be another incarnation of ITS#5251 (duplicate results > from getaddrinfo()). Indeed removing 'localhost' from /etc/hosts in the line starting with '::1' solved this. On my former openSUSE 10.3 system I had disabled IPv6 completely. Hmm... So you can mark ITS#5644 as duplicate of ITS#5251. Ciao, Michael.

1 0

Re: (ITS#5642) Double free on exit, when specific attributetype is defined
by h.b.furuseth＠usit.uio.no 06 Aug '08

06 Aug '08

hyc(a)symas.com writes: >> attributetype ( 278.1.3.6.1 NAME 'requireClass' SUP objectClass ) > > This is now fixed in HEAD. Slapd should to refuse to start with a bogus OID like that. OIDs start with components <0-1>.<0-39> or 2.<any>. The LDAP standard doesn't seem to mention this, but RFC 4517 does defer to X.680 (the ASN.1 spec), which since 1998 has deferred to X.660 - which I don't have:-( Anyway, my reference is John Larmouth's _ASN.1 Complete_. And it can be inferred from the BER encoding of the OBJECT IDENTIFIER type. -- Hallvard

1 0

Re: (ITS#5644) make test000 core dumps
by rhafer＠suse.de 06 Aug '08

06 Aug '08

On Dienstag, 5. August 2008, michael(a)stroeder.com wrote: > This is a multi-part message in MIME format. > --------------000504090501070603080100 > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8bit > > Pierangelo Masarati wrote: > > ----- "Michael Ströder" <michael(a)stroeder.com> wrote: > >> Pierangelo Masarati wrote: > >>> Are you sure you're loading the sasl mechs you've compiled for? > >> > >> That's a typical issue with SASL (see SASL_PATH, in case). > >> > >>>> #2 0x405df014 in ?? () from /usr/lib/libldap-2.4.so.2 > >> > >> Hmm, it seems the problem is rather that the LDAP client libs from > >> the > >> > >> RPM package installed by openSUSE are loaded instead the ones from > >> the > >> > >> build directory. That's bad. Any way around this when running > >> 'make test'? > > > > LD_LIBRARY_PATH to your just built libs? > > Hmm, I don't have a clue what's going on. I tried with my RE24 source > tree from which I've successfully built a couple of days ago. I've > removed openSUSE packages for OpenLDAP client libs and > cyrus-sasl-ldap-auxprop. Still no success. It does not core dump > anymore but slapd does not start (see below). > > Ciao, Michael. > > -------------------------------- snip > --------------------------------- > > >>>>> Starting test000-rootdse ... > > running defines.sh > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ./scripts/test000-rootdse: line 66: kill: (21057) - No such process > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > > >>>>> Test failed > >>>>> ./scripts/test000-rootdse failed (exit 255) > [..] > make: *** [test] Error 2 > -------------------------------- snip > --------------------------------- [..] > slapd starting > daemon: listen(ldap://localhost:9011/, 5) failed errno=3D98 (Address > alre= ady in use) > lt-slapd shutdown: initiated > =3D=3D=3D=3D> bdb_cache_release_all > lt-slapd destroy: freeing system resources. > slapd stopped. > > --------------000504090501070603080100-- This might just be another incarnation of ITS#5251 (duplicate results from getaddrinfo()). -- Ralf

1 0

ITS#5581 reopened
by ando＠sys-net.it 06 Aug '08

06 Aug '08

I have re-opened this bug. I have a fix, will commit ASAP. I confirm the bug only seems to affect malformed filters in the URI. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5581) slapd: search.c:970: oc_filter: Assertion `f != ((void *)0)' failed.
by ando＠sys-net.it 06 Aug '08

06 Aug '08

----- stef(a)memberwebs.com wrote: > I get this problem with 2.4.11 (but not with 2.4.10). My slapo-unique > configuration is as follows: > > unique_uri ldap:///?cn?sub > unique_uri ldap:///?uid,login?sub?(!(disabled=TRUE)) > > The filter seems valid to me, but please correct me if I'm wrong. Does "disabled" exist? I mean: is it defined __before__ this line in your slapd.conf? Does TRUE comply with its syntax? I've checked the fix to this bug, and it seems to mischeck the validity of the filter, so if what you specify in the "filter" field of the URI is not a valid filter, the string "(?=error)" shows up instead of the normalization of your filter, causing subsequent harm to filter evaluation. This does not occur if the filter is valid, so there must be also an error on your side (I'm fixing the test, in the meanwhile, so that the error is notified while parsing the configuration). 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5586) SLAPD crashing with SIGABRT in connection.c on Solaris - reference through nil pointer
by dbb＠st-andrews.ac.uk 06 Aug '08

06 Aug '08

Thanks. Howard Chu wrote: > dbb(a)st-andrews.ac.uk wrote: >> Just an update, still present in 2.4.11, backtrace below. Still can't >> work out why it's happening, >> it's something in the way that sendmail uses ldap and not the actual >> queries that cause the crash. >> >> I can replay the connections and searches to the server, and I've used >> Suns ldap load testing software >> to load up the server way over what we ever see and I can't replicate >> the SIGABRT or crash it in any >> other way. >> >> Any help appreciated. > > In frame 5 > print *index > print connections[*index] /usr/local/SUNWspro/bin/dbx /source/openldap-2.4.11/servers/slapd/.libs/slapd ./slapd-2.4.11-core-6-8-08 For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading slapd core file header read successfully Reading ld.so.1 Reading libldap_r-2.4.so.2.1.0 Reading liblber-2.4.so.2.1.0 Reading libltdl.so.3.1.5 Reading libdb-4.2.so Reading libicuuc.so.3 Reading libicudata.so.3 Reading libsasl2.so.2.0.22 Reading libdl.so.1 Reading libssl.so.0.9.8 Reading libcrypto.so.0.9.8 Reading libresolv.so.2 Reading libgen.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libgcc_s.so.1 Reading libgcc_s.so.1 Reading libpthread.so.1 Reading libm.so.2 Reading libCrun.so.1 Reading libc_psr.so.1 t@2 (l@2) terminated by signal ABRT (Abort) 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() o> t@2 a l@2 slapd_daemon_task() signal SIGABRT in __lwp_kill() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@5 a l@5 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@8 a l@8 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@9 a l@9 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@10 a l@10 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@11 a l@11 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@12 a l@12 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() (dbx) thread t@2 t@2 (l@2) stopped in __lwp_kill at 0xfe2c0f90 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 (dbx) where current thread: t@2 [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe2c0f90 [2] raise(0x6, 0x0, 0xfe2a4a98, 0xffffffff, 0xfe2e8284, 0x6), at 0xfe25fd78 [3] abort(0xfdfff3f0, 0x1, 0xfe2e9288, 0xa83f0, 0xfe2eb298, 0x0), at 0xfe23ff98 [4] __assert(0x1a1808, 0x1a183c, 0x367, 0x0, 0xa810c, 0x1d7b80), at 0xfe2401d4 =>[5] connection_next(c = (nil), index = 0xfdfff6d4), line 871 in "connection.c" [6] connections_timeout_idle(now = 1217978957), line 225 in "connection.c" [7] slapd_daemon_task(ptr = (nil)), line 2152 in "daemon.c" (dbx) print *index *index = 33 (dbx) print connections[*index] connections[*index] = { c_struct_state = 2 c_conn_state = 1 c_conn_idx = 33 c_sd = 33 c_close_reason = 0x1a11bc "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x45fbd0 c_starttime = 1217978957 c_activitytime = 1217978957 c_connid = 436161U c_peer_domain = { bv_len = 7U bv_val = 0x48fda0 "unknown" } c_peer_name = { bv_len = 22U bv_val = 0x4b34b8 "IP=138.251.30.31:34746" } c_listener = 0x23ea28 c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x2c2664 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x2c266c } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = 0x4252d8 c_sasl_sockctx = (nil) c_sasl_extra = 0x43a298 c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 0 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 0 c_n_get = 0 c_n_read = 0 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x67ac8 = &slap_send_ldap_result() c_send_search_entry = 0x68c40 = &slap_send_search_entry() c_send_search_reference = 0x6b320 = &slap_send_search_reference() c_send_ldap_extended = 0x685e8 = &slap_send_ldap_extended() c_send_ldap_intermediate = 0x68968 = &slap_send_ldap_intermediate() } (dbx) A second example in case useful /usr/local/SUNWspro/bin/dbx /source/openldap-2.4.11/servers/slapd/.libs/slapd ./slapd-2.4.11-core-1300-4-8-08 For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading slapd core file header read successfully Reading ld.so.1 Reading libldap_r-2.4.so.2.1.0 Reading liblber-2.4.so.2.1.0 Reading libltdl.so.3.1.5 Reading libdb-4.2.so Reading libicuuc.so.3 Reading libicudata.so.3 Reading libsasl2.so.2.0.22 Reading libdl.so.1 Reading libssl.so.0.9.8 Reading libcrypto.so.0.9.8 Reading libresolv.so.2 Reading libgen.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libgcc_s.so.1 Reading libgcc_s.so.1 Reading libpthread.so.1 Reading libm.so.2 Reading libCrun.so.1 Reading libc_psr.so.1 t@2 (l@2) terminated by signal ABRT (Abort) 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (dbx) where current thread: t@2 [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe2c0f90 [2] raise(0x6, 0x0, 0xfe2a4a98, 0xffffffff, 0xfe2e8284, 0x6), at 0xfe25fd78 [3] abort(0xfdfff3f0, 0x1, 0xfe2e9288, 0xa83f0, 0xfe2eb298, 0x0), at 0xfe23ff98 [4] __assert(0x1a1808, 0x1a183c, 0x367, 0x0, 0xa810c, 0x1d7b80), at 0xfe2401d4 =>[5] connection_next(c = (nil), index = 0xfdfff6d4), line 871 in "connection.c" [6] connections_timeout_idle(now = 1217851229), line 225 in "connection.c" [7] slapd_daemon_task(ptr = (nil)), line 2152 in "daemon.c" (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() o> t@2 a l@2 slapd_daemon_task() signal SIGABRT in __lwp_kill() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@5 a l@5 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() (dbx) print *index *index = 21 (dbx) print connections[*index] connections[*index] = { c_struct_state = 2 c_conn_state = 1 c_conn_idx = 21 c_sd = 21 c_close_reason = 0x1a11bc "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x435300 c_starttime = 1217851229 c_activitytime = 1217851229 c_connid = 6825U c_peer_domain = { bv_len = 7U bv_val = 0x419470 "unknown" } c_peer_name = { bv_len = 22U bv_val = 0x413908 "IP=138.251.30.32:40070" } c_listener = 0x23ea28 c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x2c16a4 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x2c16ac } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = 0x426680 c_sasl_sockctx = (nil) c_sasl_extra = 0x4346a8 c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 0 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 0 c_n_get = 0 c_n_read = 0 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x67ac8 = &slap_send_ldap_result() c_send_search_entry = 0x68c40 = &slap_send_search_entry() c_send_search_reference = 0x6b320 = &slap_send_search_reference() c_send_ldap_extended = 0x685e8 = &slap_send_ldap_extended() c_send_ldap_intermediate = 0x68968 = &slap_send_ldap_intermediate() } -- The University of St Andrews is a charity registered in Scotland : No SC013532

1 0

Re: (ITS#5641) Segmentation fault - slaptest and slapd
by ando＠sys-net.it 06 Aug '08

06 Aug '08

----- hyc(a)symas.com wrote: > hfranzke(a)tee.toshiba.de wrote: > > Full_Name: Helmut Franzke > > Version: 2.4.11 / 2.4.9 > > OS: Ubuntu server 8.04.1 / Centos 4.6 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (192.109.150.105) > > > > > > I could get slaptest/slapd to produce a segmentation fault by using > the unique > > overlay and a unique_uri with a base dn. This behaviour depends on > the position > > of the overlay/unique_uri in slapd.conf and doesn't appear if you > don't use a > > base dn regardless of the position. (I know an overlay should be > defined after > > the other configuration settings have been set. I encountered this > bug when I > > put it in the first part by mistake, see below) > > We should of course fix the SEGV, but it is already documented that > overlays > must be configured after their corresponding databases. As such, this > is not a > high priority. slapo-unique uses be_nsuffix without testing it, and it's obviously NULL until "suffix" is defined. The fix is trivial, but I can't commit right now. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5586) SLAPD crashing with SIGABRT in connection.c on Solaris - reference through nil pointer
by hyc＠symas.com 05 Aug '08

05 Aug '08

dbb(a)st-andrews.ac.uk wrote: > Just an update, still present in 2.4.11, backtrace below. Still can't > work out why it's happening, > it's something in the way that sendmail uses ldap and not the actual > queries that cause the crash. > > I can replay the connections and searches to the server, and I've used > Suns ldap load testing software > to load up the server way over what we ever see and I can't replicate > the SIGABRT or crash it in any > other way. > > Any help appreciated. In frame 5 print *index print connections[*index] -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs