help-gss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Processed: reassign 404739 to gss


From: Simon Josefsson
Subject: Re: Processed: reassign 404739 to gss
Date: Mon, 08 Jan 2007 16:09:27 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.92 (gnu/linux)

Russ Allbery <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>
>> Hi!  I just noticed this bug that was filed for gss.  I don't have
>> access to an amd64 machine.  How can we debug this further?  Should I
>> ask the bug submitter (intentionally not Cc:d) to debug this further
>> himself, or do we have a responsibility to make sure the package works
>> on amd64 without help from the bug submitter?
>
> Generally, the maintainer is responsible for trying to get the package to
> work on the architectures supported by Debian where possible, in the sense
> that if the maintainer doesn't do it, it probably won't get done.
>
> I do have an AMD64 system, so I can help debug.

Great!

It seems www.testdrive.hp.com is starting to come back online, so
maybe I can find a amd64 host to debug this.

> Here's the backtrace:
>
> Core was generated by `./krb5context'.
> Program terminated with signal 11, Segmentation fault.
> #0  gss_krb5_init_sec_context (minor_status=0x7fff0f1c180c, 
>     initiator_cred_handle=<value optimized out>, 
>     context_handle=0x7fff0f1c17e8, target_name=0x5051d0, 
>     mech_type=<value optimized out>, req_flags=14, time_req=0, 
>     input_chan_bindings=0x0, input_token=0x7fff0f1c17c0, 
> actual_mech_type=0x0, 
>     output_token=0x7fff0f1c17b0, ret_flags=0x0, time_rec=0x0) at context.c:147
> 147       rc = shishi_ap_rep_der_set (k5->ap, data + TOK_LEN, datalen - 
> TOK_LEN);
> (gdb) bt
> #0  gss_krb5_init_sec_context (minor_status=0x7fff0f1c180c, 
>     initiator_cred_handle=<value optimized out>, 
>     context_handle=0x7fff0f1c17e8, target_name=0x5051d0, 
>     mech_type=<value optimized out>, req_flags=14, time_req=0, 
>     input_chan_bindings=0x0, input_token=0x7fff0f1c17c0, 
> actual_mech_type=0x0, 
>     output_token=0x7fff0f1c17b0, ret_flags=0x0, time_rec=0x0) at context.c:147
> #1  0x0000000000401451 in main (argc=<value optimized out>, 
>     argv=<value optimized out>) at krb5context.c:294
>
> The same test passes when built with -g and no optimization flags.  k5
> isn't NULL or anything obvious, so I'm not sure where the segfault is
> coming from.

Ok, so it is actually Shishi that is crashing (although the bug could
still be in gss).  Does installing the 'shishi-dbg' package generate a
better backtrace, with file:line information inside Shishi?

Still, the optimizations going on may make it difficult to identify
the problem...  I'll see if I can build this myself, without
optimization flags.

Thanks!
Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]