Russ Allbery <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
