gssproxy

#80 gssproxy segfaults on SIGTERM
Closed: Fixed Opened by jcholast.

Closed: Fixed
Reopen Issue

GDB output:

<snip>
Program received signal SIGTERM, Terminated.
0x00007ffff63274a3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81
81      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Missing separate debuginfos, use: debuginfo-install libselinux-2.1.13-12.fc19.x86_64
(gdb) bt
#0  0x00007ffff63274a3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fffee867a93 in epoll_event_loop (tvalp=0x7fffffffe3a0, epoll_ev=0x6165b0) at ../tevent_epoll.c:650
#2  epoll_event_loop_once (ev=<optimized out>, location=<optimized out>) at ../tevent_epoll.c:931
#3  0x00007fffee8660b7 in std_event_loop_once (ev=0x616370, location=0x7fffeea6d132 "verto-tevent.c:55") at ../tevent_standard.c:112
#4  0x00007fffee862bcd in _tevent_loop_once (ev=0x616370, location=0x7fffeea6d132 "verto-tevent.c:55") at ../tevent.c:530
#5  0x00007ffff79cf31f in verto_run (ctx=ctx@entry=0x6165e0) at verto.c:578
#6  0x0000000000403c9d in main (argc=<optimized out>, argv=<optimized out>) at src/gssproxy.c:148

The program simply terminated as requested by the signal.
What sent SIGTERM to the daemon ? Do w need to catch it and terminate more gracefully ?

Uhm sorry we actually do configure verto to cacth it. We will investigate on why it is not handled more gracefully.

There was a segfault when gssproxy stopped (invalid free of the configuration sturcts), this has been resolved in 0.2.2 now (just released).

Yes, that was the segfault I meant.

Ok, so this we resolved then. Closing this ticket.

Metadata Update from @jcholast:
- Issue assigned to simo
- Issue set to the milestone: 2013 May
Metadata
None
None
None
Normal
task
gssproxy daemon
0
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.