[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SASL causes segmentation fault (ITS#3172)
At 10:17 PM 6/8/2004, quanah@stanford.edu wrote:
>So I'd say having an 8MB thread stack doesn't help the situation at all...
Well, at least now we have what appears to be a complete
stack backtrace. It is certainly down deep in Kerberos...
not sure what to suggest except to make sure running
against the latest... and build the libraries with
debugging symbols so that precise failure point can
be determined. As it stands now, I cannot see anything
in OpenLDAP Software that would cause this.
Kurt
>--On Tuesday, June 08, 2004 5:06 PM -0700 "Kurt D. Zeilenga"
><Kurt@OpenLDAP.org> wrote:
>
>After rebuilding with a 8MB thread stack size:
>
>Program received signal SIGSEGV, Segmentation fault.
>[Switching to Thread 6 (LWP 1)]
>0xfec72318 in vget_next () from /usr/local/lib/libkrb5.so.17
>(gdb) bt
>#0 0xfec72318 in vget_next () from /usr/local/lib/libkrb5.so.17
>#1 0xfec72484 in krb5_config_vget () from /usr/local/lib/libkrb5.so.17
>#2 0xfec72770 in krb5_config_vget_bool_default () from
>/usr/local/lib/libkrb5.so.17
>#3 0xfec7281c in krb5_config_get_bool_default () from
>/usr/local/lib/libkrb5.so.17
>#4 0xfec7c558 in krb5_get_host_realm_int () from
>/usr/local/lib/libkrb5.so.17
>#5 0xfec7c71c in krb5_get_host_realm () from /usr/local/lib/libkrb5.so.17
>#6 0xfec78cec in krb5_expand_hostname_realms () from
>/usr/local/lib/libkrb5.so.17
>#7 0xfec86f50 in krb5_sname_to_principal () from
>/usr/local/lib/libkrb5.so.17
>#8 0xfecb8160 in import_hostbased_name () from
>/usr/local/lib/libgssapi.so.1
>#9 0xfece20d4 in gssapi_server_mech_step () from
>/usr/local/lib/sasl2/libgssapiv2.so.2
>#10 0xff1df4ac in sasl_server_step () from /usr/local/lib/libsasl2.so.2
>#11 0xff1df190 in sasl_server_start () from /usr/local/lib/libsasl2.so.2
>#12 0x00088554 in slap_sasl_bind (op=0x2299600, rs=0x7b801ad0) at
>sasl.c:1492
>#13 0x0004ec70 in do_bind (op=0x2299600, rs=0x7b801ad0) at bind.c:301
>#14 0x0002a120 in connection_operation (ctx=0x7b801ba0, arg_v=0x2299600) at
>connection.c:1007
>#15 0xff33d6b8 in ldap_int_thread_pool_wrapper (xpool=0x16ad70) at
>tpool.c:467
>#16 0xfed5b024 in _thread_start () from /usr/lib/libthread.so.1
>#17 0xfed5b024 in _thread_start () from /usr/lib/libthread.so.1
>Previous frame identical to this frame (corrupt stack?)
>
>
>(gdb) info threads
> 9 Thread 5 0xfed51c24 in thr_yield () from
>/usr/lib/libthread.so.1
> 8 Thread 4 (LWP 3) 0xfee1d394 in _poll () from /usr/lib/libc.so.1
> 7 Thread 3 0xfed4d9b8 in _reap_wait () from
>/usr/lib/libthread.so.1
> 6 Thread 2 (LWP 2) 0xfee1eb58 in _signotifywait () from
>/usr/lib/libc.so.1
> 5 LWP 2 0xfee1eb58 in _signotifywait () from
>/usr/lib/libc.so.1
> 4 LWP 3 0xfee1d394 in _poll () from /usr/lib/libc.so.1
>* 3 Thread 6 (LWP 1) 0xfec72318 in vget_next () from
>/usr/local/lib/libkrb5.so.17
> 2 Thread 1 0xfed4da10 in _reap_wait_cancel () from
>/usr/lib/libthread.so.1
> 1 LWP 1 0xfec72318 in vget_next () from
>/usr/local/lib/libkrb5.so.17
>
>
>(gdb) thr apply all bt
>
>Thread 9 (Thread 5 ):
>#0 0xfed51c24 in thr_yield () from /usr/lib/libthread.so.1
>#1 0xff33e824 in ldap_pvt_thread_yield () at thr_posix.c:190
>#2 0x000ad7ac in bdb_do_search (op=0x1f23e0, rs=0x7c401ad0, sop=0x1f23e0,
>ps_e=0x0, ps_type=0)
> at search.c:1315
>#3 0x000a90ec in bdb_search (op=0x1f23e0, rs=0x7c401ad0) at search.c:361
>#4 0x0002dbe0 in do_search (op=0x1f23e0, rs=0x7c401ad0) at search.c:400
>#5 0x0002a3c0 in connection_operation (ctx=0x7c401ba0, arg_v=0x1f23e0) at
>connection.c:1042
>#6 0xff33d6b8 in ldap_int_thread_pool_wrapper (xpool=0x16ad70) at
>tpool.c:467
>#7 0xfed5b024 in _thread_start () from /usr/lib/libthread.so.1
>#8 0xfed5b024 in _thread_start () from /usr/lib/libthread.so.1
>Previous frame identical to this frame (corrupt stack?)
>#0 0xfec72318 in vget_next () from /usr/local/lib/libkrb5.so.17
>
>
>
>--Quanah
>
>
>--
>Quanah Gibson-Mount
>Principal Software Developer
>ITSS/Shared Services
>Stanford University
>GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html