RE: slapd chokes on PROTOS test suite (2) (ITS#2280)

[hyc@highlandsun.com]

Most likely the thread that was parsing this PDU ran out of stack space. I
note that the first parameter to ber_get_stringbvr at 0xbf5ff95c is 2091364
bytes above the fault address of 0xbf400ff8, which suggests that you were
only using a 2MB (2097152) thread stack. The current default that OpenLDAP
uses is 4MB, so it's odd to me that you would be running with only 2MB.

It will take some thought to figure out how to retrieve the amount of free
space left on the stack to avoid this crash...

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of rhafer@suse.de

> Full_Name: Ralf Haferkamp
> Version: 2.1.12 / HEAD
> OS: SuSE Linux 8.1
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (212.95.102.213)
>
>
> The tests that still fail are at least #4829 and #5105. They
> seem to be
> somehow related, because they both seem to fail in the
> recursive function
> ber_get_stringbvr and result in similar backtraces (here from #5105):
>
> Core was generated by `servers/slapd/slapd -d 1'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libresolv.so.2...done.
> Loaded symbols for /lib/libresolv.so.2
> [..]
> #1  0x080edcc8 in ber_skip_tag (ber=Cannot access memory at
> address 0xbf400ff8
> ) at decode.c:110
> #2  0x080edddc in ber_peek_tag (ber=0x81aca90,
> len=0xbf5ff968) at decode.c:173
> #3  0x080ee04b in ber_get_stringbvr (b=0xbf5ff95c, n=43566)
> at decode.c:327
> #4  0x080ee08d in ber_get_stringbvr (b=0xbf5ff95c, n=43565)
> at decode.c:381
> #5  0x080ee08d in ber_get_stringbvr (b=0xbf5ff95c, n=43564)
> at decode.c:381
> #6  0x080ee08d in ber_get_stringbvr (b=0xbf5ff95c, n=43563)
> at decode.c:381
> #7  0x080ee08d in ber_get_stringbvr (b=0xbf5ff95c, n=43562)
> at decode.c:381
> [..]
> #43564 0x080ee08d in ber_get_stringbvr (b=0xbf5ff95c, n=5) at
> decode.c:381
> #43565 0x080ee08d in ber_get_stringbvr (b=0xbf5ff95c, n=4) at
> decode.c:381
> #43566 0x080ee08d in ber_get_stringbvr (b=0xbf5ff95c, n=3) at
> decode.c:381
> #43567 0x080ee08d in ber_get_stringbvr (b=0xbf5ff95c, n=2) at
> decode.c:381
> #43568 0x080ee08d in ber_get_stringbvr (b=0xbf5ff95c, n=1) at
> decode.c:381
> #43569 0x080ee08d in ber_get_stringbvr (b=0xbf5ff95c, n=0) at
> decode.c:381
> #43570 0x080eeb3f in ber_scanf (ber=0x81aca90, fmt=0x8131375 "M}}")
>     at decode.c:769
> #43571 0x0805c557 in do_search (conn=0x404b4b8c,
> op=0x81acac0) at search.c:164
> #43572 0x0805b2ff in connection_operation (ctx=0xbf5ff968,
> arg_v=0x81acb48)
>     at connection.c:948
> #43573 0x080d0e61 in ldap_int_thread_pool_wrapper ()
> #43574 0x402311b0 in pthread_start_thread () from /lib/libpthread.so.0
>
> I didn't investigate on this further, yet. Any ideas what the
> problem could be?
>
>
>