I've gotton several slapd core files where slap has segfaulted during a GSSAPI bind. Unfortunately I can't make slapd core. But the stack trace always looks the same:
(gdb) bt #0 0xb7f3a410 in ?? () #1 0xad328d28 in ?? () #2 0x00000006 in ?? () #3 0x000056ae in ?? () #4 0xb7c0b041 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #5 0xb7c0c7d7 in *__GI_abort () at ../sysdeps/generic/abort.c:88 #6 0xb7c3e4ce in __libc_message (do_abort=2, fmt=0xb7cee5c0 "*** glibc detected *** %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:145 #7 0xb7c48196 in malloc_printerr (action=2, str=0x0, ptr=0x0) at malloc.c:5525 #8 0xb7c46e9d in _int_free (av=0xb7cfb820, mem=0x97bf77a4) at malloc.c:4235 #9 0xb7c45bfb in *__GI___libc_free (mem=0x97bf77a4) at malloc.c:3404 #10 0x0807ad56 in ch_free (ptr=0x97bf77a4) at ch_malloc.c:139 #11 0x080a5b86 in slap_sasl_authorize (sconn=0x945e1d48, context=0xad72f228, requested_user=0x945e2658 "tjsm@UMICH.EDU", rlen=14, auth_identity=0x945e2759 "tjsm@UMICH.EDU", alen=14, def_realm=0x96849538 "UMICH.EDU", urlen=9, props=0x0) at sasl.c:673 #12 0xb7e73ba3 in do_authorization (s_conn=0x945e1d48) at server.c:1163 #13 0xb7e73d18 in sasl_server_step (conn=0x945e1d48, clientin=0xa8ec5716 "`?\006\t*\206H\206?\022\001\002\002\002\001 \004", clientinlen=0, serverout=0xad329114, serveroutlen=0x56ae) at server.c:1420 #14 0x080a6984 in slap_sasl_bind (op=0x7683c860, rs=0xad329240) at sasl.c:1399 #15 0x0807d06a in fe_op_bind (op=0x7683c860, rs=0xad329240) at bind.c: 276 #16 0x0807c873 in do_bind (op=0x7683c860, rs=0xad329240) at bind.c:200 #17 0x08061a8f in connection_operation (ctx=0x0, arg_v=0x7683c860) at connection.c:1132 #18 0x08116168 in ldap_int_thread_pool_wrapper (xpool=0x81cd520) at tpool.c:478 #19 0xb7e54c6b in start_thread (arg=0xad329bb0) at pthread_create.c:261 #20 0xb7c9ad9e in clone () from /lib/libc.so.6
It looks to me that slap_sasl_authorize is freeing someting that has already been freed namely context->c_sasl_dn.
Here is the context structure:
(gdb) p *(Connection *) context $5 = {c_struct_state = 2, c_conn_state = 3, c_conn_idx = 46, c_close_reason = 0x81446c5 "?", c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, __spins = 0}, __size = '\0' <repeats 23 times>, __align = 0}, c_sb = 0x9efce118, c_starttime = 1175269483, c_activitytime = 1175269483, c_connid = 4957353, c_peer_domain = {bv_len = 7, bv_val = 0xa5863d98 "unknown"}, c_peer_name = { bv_len = 22, bv_val = 0xa368c190 "IP=141.211.14.17:58013"}, c_listener = 0x81c02c8, c_sasl_bind_in_progress = 1, c_sasl_bind_mech = { bv_len = 6, bv_val = 0x8435bbc0 "GSSAPI"}, c_sasl_dn = {bv_len = 35, bv_val = 0x97bf77a4 "hasSubordinates1\a\004 \005FALSESESESEALSEALSEEALSEALSEavin,ou=People,dc=umich,dc=edu\004% uid=jleasia,ou=People,dc=umich,dc=edu\004 $uid=ktexas,ou=People,dc=umich,dc=edu\004! uid=lmp,ou=People,dc=umich,dc=edu\004%uid=philr"...}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x81e6dc8, c_authz_cookie = 0x0, c_authz = { sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = { bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 3, c_ops = {stqh_first = 0x7683c860, stqh_last = 0x7683c92c}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0xad72f2d0}, c_write_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, __spins = 0}, __size = '\0' <repeats 23 times>, __align = 0}, c_write_cv = {__data = {__lock = 0, __futex = 1782, __total_seq = 891, __wakeup_seq = 891, __woken_seq = 891, __mutex = 0xad72f238, __nwaiters = 0, __broadcast_seq = 0}, __size = "\000\000\000\000?\006\000\000{\003\000\000\000\000\000 \000{\003\000\000\000\000\000\000{\003\000\000\000\000\000\0008?r?", '\0' <repeats 11 times>, __align = 7653631721472}, c_currentber = 0x968f5370, c_writewaiter = 0, c_is_tls = 0, c_needs_tls_accept = 0, c_sasl_layers = 0, c_sasl_done = 0, c_sasl_authctx = 0x945e1d48, c_sasl_sockctx = 0x0, c_sasl_extra = 0x927e6f80, c_sasl_bindop = 0x7683c860, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_cookie = 0, ps_count = 0}, c_n_ops_received = 4, c_n_ops_executing = 1, c_n_ops_pending = 0, c_n_ops_completed = 3, c_n_get = 4, c_n_read = 4, c_n_write = 0, c_pb = 0x0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x806fb10 <slap_send_ldap_result>, c_send_search_entry = 0x80714a0 <slap_send_search_entry>, c_send_search_reference = 0x80705d0 <slap_send_search_reference>, c_send_ldap_extended = 0x8070290 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x8070440 <slap_send_ldap_intermediate>}
Current environment: openldap-2.3.32 cyrus sasl 2.1.21 heimdal 0.6.6 linux from source - kernal 2.6.18
Any ideas?
--On Monday, April 02, 2007 2:22 PM -0400 Paul Turgyan pturgyan@umich.edu wrote:
I've gotton several slapd core files where slap has segfaulted during a GSSAPI bind. Unfortunately I can't make slapd core. But the stack trace always looks the same:
Current environment: openldap-2.3.32 cyrus sasl 2.1.21 heimdal 0.6.6 linux from source - kernal 2.6.18
Any ideas?
I use:
OpenLDAP 2.3.34 Cyrus SASL 2.1.21 Heimdal 0.7.2
And have no such problem.
As I recall, I had to specify particular flags to my Heimdal 0.6 build back when I was using it to ensure that it used the re-entrant libraries properly. That was fixed with 0.7.x releases.
You may want to upgrade (openldap & heimdal) and see if it still occurs.
--Quanah
-- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
--On Monday, April 02, 2007 11:41 AM -0700 Quanah Gibson-Mount quanah@stanford.edu wrote:
--On Monday, April 02, 2007 2:22 PM -0400 Paul Turgyan pturgyan@umich.edu wrote:
I've gotton several slapd core files where slap has segfaulted during a GSSAPI bind. Unfortunately I can't make slapd core. But the stack trace always looks the same:
Current environment: openldap-2.3.32 cyrus sasl 2.1.21 heimdal 0.6.6 linux from source - kernal 2.6.18
Any ideas?
I use:
OpenLDAP 2.3.34 Cyrus SASL 2.1.21
Slight correction, I'm using Cyrus SASL 2.1.22. I don't recall having any issues with 2.1.21 though.
--Quanah
-- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
On Apr 2, 2007, at 2:41 PM, Quanah Gibson-Mount wrote:
--On Monday, April 02, 2007 2:22 PM -0400 Paul Turgyan pturgyan@umich.edu wrote:
I've gotton several slapd core files where slap has segfaulted during a GSSAPI bind. Unfortunately I can't make slapd core. But the stack trace always looks the same:
Current environment: openldap-2.3.32 cyrus sasl 2.1.21 heimdal 0.6.6 linux from source - kernal 2.6.18
Any ideas?
I use:
OpenLDAP 2.3.34 Cyrus SASL 2.1.21 Heimdal 0.7.2
We reverted to heimdal 0.6.6 when 0.7.2 uncovered a memory leak in the dns libraries. Cyrus SASL 2.1.22 caused a problem between our IMAP servers and some IMAP clients. So we never upgraded to 2.1.22.
openldap-software@openldap.org