gssproxy

#86 Segmentation fault in gssproxy.so
Closed: Invalid Opened by jcholast.

Closed: Invalid
Reopen Issue

While testing Java with native GSSAPI and GSS proxy, I regularly (not always) get segmentation faults in gssproxy.so:

<snip>
Program received signal SIGSEGV, Segmentation fault.
gpm_make_call (proc=proc@entry=6, arg=arg@entry=0x7f5c41d1bd90, res=res@entry=0x7f5c41d1bcf0) at src/client/gpm_common.c:404
404 {
(gdb) bt
#0  gpm_make_call (proc=proc@entry=6, arg=arg@entry=0x7f5c41d1bd90, res=res@entry=0x7f5c41d1bcf0) at src/client/gpm_common.c:404
#1  0x00007f5c406114c2 in gpm_acquire_cred (minor_status=minor_status@entry=0x7f5c41d1bf7c, desired_name=<optimized out>, time_req=time_req@entry=2147483647, desired_mechs=desired_mechs@entry=0x7f5c581aba90, 
    cred_usage=cred_usage@entry=1, output_cred_handle=output_cred_handle@entry=0x7f5c581aba70, actual_mechs=actual_mechs@entry=0x0, time_rec=time_rec@entry=0x7f5c41d1c024) at src/client/gpm_acquire_cred.c:112
#2  0x00007f5c406154d9 in gssi_acquire_cred (minor_status=0x7f5c41d1c11c, desired_name=0x0, time_req=2147483647, desired_mechs=0x7f5c581aba90, cred_usage=1, output_cred_handle=0x7f5c41d1c030, actual_mechs=0x0, 
    time_rec=0x7f5c41d1c024) at src/mechglue/gpp_acquire_cred.c:131
#3  0x00007f5c417dc6ab in gss_add_cred_from (minor_status=minor_status@entry=0x7f5c41d1c11c, input_cred_handle=<optimized out>, desired_name=desired_name@entry=0x0, desired_mech=<optimized out>, 
    cred_usage=cred_usage@entry=1, initiator_time_req=initiator_time_req@entry=2147483647, acceptor_time_req=acceptor_time_req@entry=2147483647, cred_store=cred_store@entry=0x0, 
    output_cred_handle=output_cred_handle@entry=0x0, actual_mechs=actual_mechs@entry=0x0, initiator_time_rec=initiator_time_rec@entry=0x7f5c41d1c120, acceptor_time_rec=acceptor_time_rec@entry=0x7f5c41d1c124)
    at g_acquire_cred.c:460
#4  0x00007f5c417dcb7b in gss_acquire_cred_from (minor_status=0x7f5c41d1c1e4, desired_name=0x0, time_req=<optimized out>, desired_mechs=0x7f5c581a8be0, cred_usage=<optimized out>, 
    cred_store=cred_store@entry=0x0, output_cred_handle=0x7f5c41d1c1e8, actual_mechs=actual_mechs@entry=0x0, time_rec=time_rec@entry=0x0) at g_acquire_cred.c:188
#5  0x00007f5c417dcd44 in gss_acquire_cred (minor_status=<optimized out>, desired_name=<optimized out>, time_req=<optimized out>, desired_mechs=<optimized out>, cred_usage=<optimized out>, 
    output_cred_handle=<optimized out>, actual_mechs=0x0, time_rec=0x0) at g_acquire_cred.c:113
#6  0x00007f5c41a19b9c in Java_sun_security_jgss_wrapper_GSSLibStub_acquireCred (env=0x7f5c4c4091d8, jobj=0x7f5c41d1c2e0, pName=0, reqTime=2147483647, usage=1)
    at ../../../../../src/share/native/sun/security/jgss/wrapper/GSSLibStub.c:527
#7  0x00007f5c65011f50 in ?? ()
#8  0x00007f5c0000000d in ?? ()
#9  0x00007f5c4c409000 in ?? ()
#10 0x00007f5c41d1c2c0 in ?? ()
#11 0x00007f5c6501cbe3 in ?? ()
#12 0x00007f5c65005410 in ?? ()
#13 0x0000000a00000000 in ?? ()
#14 0x00007f5c41d1c260 in ?? ()
#15 0x00000000f25adae0 in ?? ()
#16 0x00007f5c41d1c2e0 in ?? ()
#17 0x00000000f25af488 in ?? ()
#18 0x0000000000000000 in ?? ()

A lot of arguments are optimized away whic makes it hard to see what is going on.
Any chance you can reproduce under valgrind ?

It could possibly be resolved by the fix provided for #85.

The fix for #85 does not resolve this issue.

My valgrind-fu is rather poor, so I recompiled gssproxy and krb5 with -O0 and reproduced under gdb with that. The backtrace is:

#0  0x00007f57aae009c7 in gpm_make_call (proc=1667593007, arg=0x3a6120000000000, res=0x0) at src/client/gpm_common.c:404
#1  0x00007f57aadfc1b8 in gpm_acquire_cred (minor_status=0x7f57b0717f1c, desired_name=0x0, time_req=2147483647, desired_mechs=0x7f57b80c71d0, cred_usage=1, output_cred_handle=0x7f57b80c7030, actual_mechs=0x0, 
    time_rec=0x7f57b0717fe4) at src/client/gpm_acquire_cred.c:112
#2  0x00007f57aae01467 in gssi_acquire_cred (minor_status=0x7f57b07180e8, desired_name=0x0, time_req=2147483647, desired_mechs=0x7f57b80c71d0, cred_usage=1, output_cred_handle=0x7f57b0717ff8, actual_mechs=0x0, 
    time_rec=0x7f57b0717fe4) at src/mechglue/gpp_acquire_cred.c:131
#3  0x00007f57b00b6ad0 in gss_add_cred_from (minor_status=0x7f57b07180e8, input_cred_handle=0x7f57b80c7050, desired_name=0x0, desired_mech=0x7f57b80c7250, cred_usage=1, initiator_time_req=2147483647, 
    acceptor_time_req=2147483647, cred_store=0x0, output_cred_handle=0x0, actual_mechs=0x0, initiator_time_rec=0x7f57b07180ec, acceptor_time_rec=0x7f57b07180f0) at g_acquire_cred.c:460
#4  0x00007f57b00b6310 in gss_acquire_cred_from (minor_status=0x7f57b07181e4, desired_name=0x0, time_req=2147483647, desired_mechs=0x7f57b80c6280, cred_usage=1, cred_store=0x0, 
    output_cred_handle=0x7f57b07181e8, actual_mechs=0x0, time_rec=0x0) at g_acquire_cred.c:188
#5  0x00007f57b00b6124 in gss_acquire_cred (minor_status=0x7f57b07181e4, desired_name=0x0, time_req=2147483647, desired_mechs=0x7f57b80c6280, cred_usage=1, output_cred_handle=0x7f57b07181e8, actual_mechs=0x0, 
    time_rec=0x0) at g_acquire_cred.c:113
#6  0x00007f57b030bb9c in Java_sun_security_jgss_wrapper_GSSLibStub_acquireCred (env=0x7f57ac1799d8, jobj=0x7f57b07182e0, pName=0, reqTime=2147483647, usage=1)
    at ../../../../../src/share/native/sun/security/jgss/wrapper/GSSLibStub.c:527
#7  0x00007f57d5011f50 in ?? ()
#8  0x00007f570000000d in ?? ()
#9  0x00007f57ac179800 in ?? ()
#10 0x00007f57b07182c0 in ?? ()
#11 0x00007f57d501cbe3 in ?? ()
#12 0x00007f57d5005410 in ?? ()
#13 0x0000000a00000000 in ?? ()
#14 0x00007f57b0718260 in ?? ()
#15 0x00000000f259b638 in ?? ()
#16 0x00007f57b07182e0 in ?? ()
#17 0x00000000f259cfe0 in ?? ()
#18 0x0000000000000000 in ?? ()

proc and arg make no sense, looks like stack corruption.
valgrind can help finding out what is causing the stack corruption, otherwise we are a bit in the dark.

Link to Jan's bt full: http://pastebin.test.redhat.com/143885

We weren't able to reliably reproduce. Deferring for now.

Couldn't repro, please reopen if still present with a full stacktrace

Metadata Update from @jcholast:
- Issue assigned to simo
- Issue set to the milestone: 2015 September
Metadata
None
None
None
Normal
defect
client library
todo
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.