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 debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to