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