[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: SASL causes segmentation fault (ITS#3172)




--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


So I'd say having an 8MB thread stack doesn't help the situation at all...

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html