Full_Name: Aleksey Version: 2.4.19 OS: Freebsd7.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.93.136.26) Openldap 2.4.19 installed from freebsd ports. All configs in defauls Freebsd 7.2 amd64 Slapd built with the "-g" flag and install with the make install STRIP="" Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. In slapd config added using hdb as backend and indexes. Testing database consist of 1000 users accounts with minimum attributes. On stress test load slapd Segmentation fault in 10-30 sec. #ldd /usr/local/libexec/slapd /usr/local/libexec/slapd: libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) libc.so.7 => /lib/libc.so.7 (0x8015f5000) #gdb /usr/local/libexec/slapd (gdb) run -d 0 Starting program: /usr/local/libexec/slapd -d 0 [New LWP 100311] [New Thread 0x801a020b0 (LWP 100311)] [New Thread 0x801a02880 (LWP 100073)] [New Thread 0x8034040b0 (LWP 100076)] [New Thread 0x803404240 (LWP 100077)] [New Thread 0x8034043d0 (LWP 100078)] [New Thread 0x803404560 (LWP 100116)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x803404560 (LWP 100116)] 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address 0x7ffffd9f9f38: Bad s. ) at idl.c:511 511 { (gdb) (gdb) (gdb) where #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address 0x7ffffd9f9f38: dress. ) at idl.c:511 #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, txn=0x80352b040, k=0x8069005 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, ava=0x7ffffda7a4f0, ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, rtxn=0x80352b040, f=0x7ffffda7a550, ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, flist=0x7ffffda7a5 f type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at filterindex.c:581 #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, rtxn=0x80352b040, f=0x7ffffda7a530, ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, flist=0x7ffffda7a5 f type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at filterindex.c:581 #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, rtxn=0x80352b040, f=0x7ffffda7a570, ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, e=0x7ffffda7a71 tx n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at search.c:586 #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at search.c:366 #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at search.c:217 #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, arg_v=0x803521000) at connection .c:1123 #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) at connection.c:125 9 #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from /usr/local/lib/libldap_r-2.4.so. #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 #16 0x0000000000000000 in ?? () Error accessing memory address 0x7ffffdbfb000: Bad address.
Hello, Aleksey. > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > Freebsd 7.2 amd64 Slapd built with the "-g" flag and install with > the make install STRIP="" Okay. > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) At the same time? Your ldd list below shows only berkeley db 4.6. These don't mix... > In slapd config added using hdb as backend and indexes. Testing > database consist of 1000 users accounts with minimum attributes. On > stress test load slapd Segmentation fault in 10-30 sec. What sort of operations? > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x803404560 (LWP 100116)] > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > address > 0x7ffffd9f9f38: Bad s. > ) at idl.c:511 Does it always fail at the same location? How reproducible is this? Matthew Backes Symas Corporation mbackes@symas.com
* mbackes@symas.com <mbackes@symas.com> [2009-11-10 22:55:10 +0000]: > Hello, Aleksey. > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > > Freebsd 7.2 amd64 Slapd built with the "-g" flag and install with > > the make install STRIP="" > > Okay. > > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > > > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) > > At the same time? Your ldd list below shows only berkeley db 4.6. > These don't mix... Not same time. I tried with both backends. Results are same. > > > In slapd config added using hdb as backend and indexes. Testing > > database consist of 1000 users accounts with minimum attributes. On > > stress test load slapd Segmentation fault in 10-30 sec. > > What sort of operations? Reading (Binds and searches). Test script is loop of id command checking ldap via nss_ldap. > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x803404560 (LWP 100116)] > > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > > address > > 0x7ffffd9f9f38: Bad s. > > ) at idl.c:511 > > Does it always fail at the same location? How reproducible is this? Often it is fail in "hdb_idl_fetch_key (be=Error accessing memory address". 100% Reproducible on different hardware. On our normal work, slapd fails every 2-3 hours, on stress test slapd fail in 10-30 sec. Problem on freebsd7.x,8 and openldap2.3.43,2.4.18,2.4.19 I tryed on debian lenny and openldap2.4.11 and netbsd5.0.1 and openldap2.4.16 it rock stable. I think problem some where in freebsd and bdb backends. Because freebsd7.1 openldap2.3.43 with depricated ldbm don`t fail on reading. Ask if need any information. Also I can give a shell access to testing server. > > Matthew Backes > Symas Corporation > mbackes@symas.com -- Email: alexs@ulgsm.ru Email/Jabber: alexs@ulgsm.ru
alexs@ulgsm.ru wrote: > Full_Name: Aleksey > Version: 2.4.19 > OS: Freebsd7.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.93.136.26) > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > Freebsd 7.2 amd64 > Slapd built with the "-g" flag and install with the make install STRIP="" > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > In slapd config added using hdb as backend and indexes. > > Testing database consist of 1000 users accounts with minimum attributes. > > On stress test load slapd Segmentation fault in 10-30 sec. Looks like you've had a stack overrun. The "be" parameter should be the same in your frame 0 and frame 1. > #gdb /usr/local/libexec/slapd > (gdb) run -d 0 > Starting program: /usr/local/libexec/slapd -d 0 > [New LWP 100311] > [New Thread 0x801a020b0 (LWP 100311)] > [New Thread 0x801a02880 (LWP 100073)] > [New Thread 0x8034040b0 (LWP 100076)] > [New Thread 0x803404240 (LWP 100077)] > [New Thread 0x8034043d0 (LWP 100078)] > [New Thread 0x803404560 (LWP 100116)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x803404560 (LWP 100116)] > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > 0x7ffffd9f9f38: Bad s. > ) at idl.c:511 > 511 { > (gdb) > (gdb) > (gdb) where > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > address 0x7ffffd9f9f38: dress. > ) at idl.c:511 > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > txn=0x80352b040, k=0x8069005 > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > ava=0x7ffffda7a4f0, > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a550, > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > filterindex.c:581 > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a530, > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > filterindex.c:581 > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a570, > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > e=0x7ffffda7a71 tx > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:586 > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:366 > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:217 > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > arg_v=0x803521000) at connection > .c:1123 > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > at connection.c:125 > 9 > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > /usr/local/lib/libldap_r-2.4.so. > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > #16 0x0000000000000000 in ?? () > Error accessing memory address 0x7ffffdbfb000: Bad address. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Open to Feedback
* hyc@symas.com <hyc@symas.com> [2009-11-15 17:58:03 +0000]: > alexs@ulgsm.ru wrote: > > Full_Name: Aleksey > > Version: 2.4.19 > > OS: Freebsd7.2 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (93.93.136.26) > > > > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > > Freebsd 7.2 amd64 > > Slapd built with the "-g" flag and install with the make install STRIP="" > > > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > > In slapd config added using hdb as backend and indexes. > > > > Testing database consist of 1000 users accounts with minimum attributes. > > > > On stress test load slapd Segmentation fault in 10-30 sec. > > Looks like you've had a stack overrun. Is it OS issue? >The "be" parameter should be the same in your frame 0 and frame 1. I don't understand. It's need to make them same? Or what i need to do? :) > > > #gdb /usr/local/libexec/slapd > > (gdb) run -d 0 > > Starting program: /usr/local/libexec/slapd -d 0 > > [New LWP 100311] > > [New Thread 0x801a020b0 (LWP 100311)] > > [New Thread 0x801a02880 (LWP 100073)] > > [New Thread 0x8034040b0 (LWP 100076)] > > [New Thread 0x803404240 (LWP 100077)] > > [New Thread 0x8034043d0 (LWP 100078)] > > [New Thread 0x803404560 (LWP 100116)] > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x803404560 (LWP 100116)] > > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > > 0x7ffffd9f9f38: Bad s. > > ) at idl.c:511 > > 511 { > > (gdb) > > (gdb) > > (gdb) where > > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > > address 0x7ffffd9f9f38: dress. > > ) at idl.c:511 > > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > > txn=0x80352b040, k=0x8069005 > > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > > ava=0x7ffffda7a4f0, > > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a550, > > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > > flist=0x7ffffda7a5 f > > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > > filterindex.c:581 > > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a530, > > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > > flist=0x7ffffda7a5 f > > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > > filterindex.c:581 > > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a570, > > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > > e=0x7ffffda7a71 tx > > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:586 > > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:366 > > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:217 > > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > > arg_v=0x803521000) at connection > > .c:1123 > > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > > at connection.c:125 > > 9 > > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > > /usr/local/lib/libldap_r-2.4.so. > > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > > #16 0x0000000000000000 in ?? () > > Error accessing memory address 0x7ffffdbfb000: Bad address. > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Email: alexs@ulgsm.ru Email/Jabber: alexs@ulgsm.ru
moved from Incoming to Software Bugs
* alexs@ulgsm.ru <alexs@ulgsm.ru> [2009-11-05 07:43:02 +0000]: New OpenLdapd 2.4.21 on new freebsd 8.0 is still crashed. I can make a public test server, to let some one check my configs and see faults. Also intresting have any body same failures? > Full_Name: Aleksey > Version: 2.4.19 > OS: Freebsd7.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.93.136.26) > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > Freebsd 7.2 amd64 > Slapd built with the "-g" flag and install with the make install STRIP="" > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > In slapd config added using hdb as backend and indexes. > > Testing database consist of 1000 users accounts with minimum attributes. > > On stress test load slapd Segmentation fault in 10-30 sec. > > > #ldd /usr/local/libexec/slapd > /usr/local/libexec/slapd: > libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) > liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) > libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) > libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) > libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) > libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) > libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) > libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) > libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) > libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) > libc.so.7 => /lib/libc.so.7 (0x8015f5000) > > > > > #gdb /usr/local/libexec/slapd > (gdb) run -d 0 > Starting program: /usr/local/libexec/slapd -d 0 > [New LWP 100311] > [New Thread 0x801a020b0 (LWP 100311)] > [New Thread 0x801a02880 (LWP 100073)] > [New Thread 0x8034040b0 (LWP 100076)] > [New Thread 0x803404240 (LWP 100077)] > [New Thread 0x8034043d0 (LWP 100078)] > [New Thread 0x803404560 (LWP 100116)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x803404560 (LWP 100116)] > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > 0x7ffffd9f9f38: Bad s. > ) at idl.c:511 > 511 { > (gdb) > (gdb) > (gdb) where > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > address 0x7ffffd9f9f38: dress. > ) at idl.c:511 > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > txn=0x80352b040, k=0x8069005 > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > ava=0x7ffffda7a4f0, > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a550, > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > filterindex.c:581 > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a530, > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > filterindex.c:581 > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a570, > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > e=0x7ffffda7a71 tx > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:586 > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:366 > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:217 > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > arg_v=0x803521000) at connection > .c:1123 > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > at connection.c:125 > 9 > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > /usr/local/lib/libldap_r-2.4.so. > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > #16 0x0000000000000000 in ?? () > Error accessing memory address 0x7ffffdbfb000: Bad address. -- alexs
* alexs@ulgsm.ru <alexs@ulgsm.ru> [2010-01-19 07:25:25 +0000]: > * alexs@ulgsm.ru <alexs@ulgsm.ru> [2009-11-05 07:43:02 +0000]: > > OpenLDAP 2.4.22, 8.1-PRERELEASE is still crashed. > > > New OpenLdapd 2.4.21 on new freebsd 8.0 is still crashed. > I can make a public test server, to let some one check my configs and > see faults. > > Also intresting have any body same failures? > > > > > > Full_Name: Aleksey > > Version: 2.4.19 > > OS: Freebsd7.2 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (93.93.136.26) > > > > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > > Freebsd 7.2 amd64 > > Slapd built with the "-g" flag and install with the make install STRIP="" > > > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > > In slapd config added using hdb as backend and indexes. > > > > Testing database consist of 1000 users accounts with minimum attributes. > > > > On stress test load slapd Segmentation fault in 10-30 sec. > > > > > > #ldd /usr/local/libexec/slapd > > /usr/local/libexec/slapd: > > libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) > > liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) > > libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) > > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) > > libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) > > libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) > > libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) > > libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) > > libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) > > libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) > > libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) > > libc.so.7 => /lib/libc.so.7 (0x8015f5000) > > > > > > > > > > #gdb /usr/local/libexec/slapd > > (gdb) run -d 0 > > Starting program: /usr/local/libexec/slapd -d 0 > > [New LWP 100311] > > [New Thread 0x801a020b0 (LWP 100311)] > > [New Thread 0x801a02880 (LWP 100073)] > > [New Thread 0x8034040b0 (LWP 100076)] > > [New Thread 0x803404240 (LWP 100077)] > > [New Thread 0x8034043d0 (LWP 100078)] > > [New Thread 0x803404560 (LWP 100116)] > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x803404560 (LWP 100116)] > > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > > 0x7ffffd9f9f38: Bad s. > > ) at idl.c:511 > > 511 { > > (gdb) > > (gdb) > > (gdb) where > > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > > address 0x7ffffd9f9f38: dress. > > ) at idl.c:511 > > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > > txn=0x80352b040, k=0x8069005 > > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > > ava=0x7ffffda7a4f0, > > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a550, > > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > > flist=0x7ffffda7a5 f > > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > > filterindex.c:581 > > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a530, > > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > > flist=0x7ffffda7a5 f > > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > > filterindex.c:581 > > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a570, > > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > > e=0x7ffffda7a71 tx > > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:586 > > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:366 > > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:217 > > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > > arg_v=0x803521000) at connection > > .c:1123 > > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > > at connection.c:125 > > 9 > > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > > /usr/local/lib/libldap_r-2.4.so. > > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > > #16 0x0000000000000000 in ?? () > > Error accessing memory address 0x7ffffdbfb000: Bad address. -- alexs
* alexs@ulgsm.ru <alexs@ulgsm.ru> [2010-01-19 07:25:25 +0000]: OpenLDAP 2.4.25, 8.2-RELEASE is still crashed. -- alexs
changed state Feedback to Open
changed notes moved from Software Bugs to Build
FreeBSD-specific, need larger LDAP_PVT_THREAD_STACK_SIZE
Hi Alex, Do you encounter this issue with back-mdb as well? Regards, Quanah