On Wed, May 13, 2009 at 10:20:46AM -0400, Sam Hartman wrote:
> Any chance you could see where it's segfaulting with a backtrace or
> something? As is, the bug's not much to go on.
A normal backtrace, just for the documentation:
| Starting program: /usr/sbin/rpc.gssd -f
| (no debugging symbols found)
| (no debugging symbols found)
| (no debugging symbols found)
| (no debugging symbols found)
| (no debugging symbols found)
| [Thread debugging using libthread_db enabled]
| [New Thread 0xb7d826e0 (LWP 1987)]
|
| Program received signal SIGSEGV, Segmentation fault.
| [Switching to Thread 0xb7d826e0 (LWP 1987)]
| 0x0804a3b5 in ?? ()
| (gdb) bt
| #0 0x0804a3b5 in ?? ()
| #1 0xbff6a518 in ?? ()
| #2 0xbff6a530 in ?? ()
| #3 0x00000001 in ?? ()
| #4 0xbff6a514 in ?? ()
| #5 0xffffffff in ?? ()
| #6 0xb806bff4 in ?? () from /lib/ld-linux.so.2
| #7 0x080488a8 in ?? ()
| #8 0xb806c670 in ?? ()
| #9 0xbff6a510 in ?? ()
| #10 0xb805ce2b in ?? () from /lib/ld-linux.so.2
| #11 0x0804c812 in ?? ()
| #12 0x0996d1c8 in ?? ()
| #13 0xbff6a564 in ?? ()
| #14 0x08051868 in ?? ()
| #15 0x000003e8 in ?? ()
| #16 0x00000000 in ?? ()
A backtrace with a debugging build:
| Program received signal SIGSEGV, Segmentation fault.
| [Switching to Thread 0xb7e146e0 (LWP 10061)]
| 0x0804a795 in serialize_krb5_ctx (ctx=0x8b8db70, buf=0xbfdfc324, endtime=0x0)
at context_lucid.c:189
| 189 vers = ((gss_krb5_lucid_context_version_t
*)return_ctx)->version;
| (gdb) bt
| #0 0x0804a795 in serialize_krb5_ctx (ctx=0x8b8db70, buf=0xbfdfc324,
endtime=0x0) at context_lucid.c:189
| #1 0x0804cbda in handle_krb5_upcall (clp=0x8b8c800) at gssd_proc.c:894
| #2 0x0804b59b in gssd_run () at gssd_main_loop.c:81
| #3 0x0804b283 in main (argc=2, argv=0x0) at gssd.c:191
It does:
| maj_stat = gss_export_lucid_sec_context(&min_stat, &ctx, 1, &return_ctx);
Which results in:
| (gdb) p maj_stat
| $4 = 0
| (gdb) p min_stat
| $5 = 2249944323
| (gdb) p return_ctx
| $6 = (void *) 0x1
And the extended backtrace:
| #0 gss_krb5_export_lucid_sec_context (minor_status=0xbfdeb214,
context_handle=0x8cde06c, version=1, kctx=0xbfdeb210)
| at ../../../../src/lib/gssapi/krb5/krb5_gss_glue.c:133
| #1 0xb7fa6a67 in gss_export_lucid_sec_context (minor_status=0xbfdeb214,
context_handle=0xbfdeb230, version=1,
| internal_buffer=0xbfdeb210) at g_lucid_context.c:65
| #2 0x0804ad09 in serialize_krb5_ctx (ctx=0x8cde068, buf=0xbfdeb274,
endtime=0x0) at context_lucid.c:180
| #3 0x0804a717 in serialize_context_for_kernel (ctx=0x8cde068,
buf=0xbfdeb274, mech=0x8053368, endtime=0x0) at context.c:53
| #4 0x0804d58c in handle_krb5_upcall (clp=0x8cda800) at gssd_proc.c:894
| #5 0x0804b750 in scan_poll_results (ret=1) at gssd_main_loop.c:81
| #6 0x0804b9f9 in gssd_run () at gssd_main_loop.c:151
| #7 0x0804b69c in main (argc=4, argv=0xbfdeb4f4) at gssd.c:191
gss_export_lucid_sec_context is a simple wrapper around
gss_krb5_export_lucid_sec_context.
Some data from within the gss_krb5_export_lucid_sec_context function:
| (gdb) n
| 163 in ../../../../src/lib/gssapi/krb5/krb5_gss_glue.c
| (gdb) p *kctx
| $8 = (void *) 0x0
line 163: *kctx = *((void **)data_set->elements[0].value);
| (gdb) n
| 168 in ../../../../src/lib/gssapi/krb5/krb5_gss_glue.c
| (gdb) p *kctx
| $9 = (void *) 0x1
| (gdb) p data_set
| $10 = (gss_buffer_set_t) 0x8cdbe40
| (gdb) p *data_set
| $11 = {count = 1, elements = 0x8cddf98}
| (gdb) p *data_set.elements
| $12 = {length = 4, value = 0x8ce01b0}
| (gdb) p data_set.elements.value
| $13 = (void *) 0x8ce01b0
| (gdb) p {void **}data_set.elements.value
| $15 = (void **) 0x1
Bastian
--
Warp 7 -- It's a law we can live with.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
