Bug 1197175

Summary: [abrt] spice-gtk-tools: signal_handler(): spicy killed by SIGABRT
Product: [Fedora] Fedora Reporter: Michele <f.michele89>
Component: spice-gtkAssignee: Marc-Andre Lureau <marcandre.lureau>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: alon, berrange, cfergeau, crobinso, hdegoede, jirinek, marcandre.lureau, sandmann, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/e80608110c4cdef9a8f0d56c7676f15813b1ef3f
Whiteboard: abrt_hash:e4b669c5a4f97c0c62b7818307fce03b053279f8
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-29 23:38:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: build_ids
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Michele 2015-02-27 16:30:59 UTC 
Description of problem:
Start a remote spicy session then kill spicy with a SIGABRT or shutdown pc

Version-Release number of selected component:
spice-gtk-tools-0.27-3.fc21

Additional info:
reporter:       libreport-2.3.0
backtrace_rating: 4
cmdline:        spicy -h telco.di.unisa.it -p 6789
crash_function: signal_handler
executable:     /usr/bin/spicy
kernel:         3.18.7-200.fc21.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (4 frames)
 #2 signal_handler at spicy.c:1725
 #4 fsync at ../sysdeps/unix/syscall-template.S:81
 #5 write_to_temp_file at gfileutils.c:1107
 #6 g_file_set_contents at gfileutils.c:1197
Comment 1 Michele 2015-02-27 16:31:03 UTC 
Created attachment 996105 [details]
File: backtrace
Comment 2 Michele 2015-02-27 16:31:04 UTC 
Created attachment 996106 [details]
File: build_ids
Comment 3 Michele 2015-02-27 16:31:06 UTC 
Created attachment 996107 [details]
File: cgroup
Comment 4 Michele 2015-02-27 16:31:07 UTC 
Created attachment 996108 [details]
File: core_backtrace
Comment 5 Michele 2015-02-27 16:31:09 UTC 
Created attachment 996109 [details]
File: dso_list
Comment 6 Michele 2015-02-27 16:31:10 UTC 
Created attachment 996110 [details]
File: environ
Comment 7 Michele 2015-02-27 16:31:11 UTC 
Created attachment 996111 [details]
File: limits
Comment 8 Michele 2015-02-27 16:31:13 UTC 
Created attachment 996112 [details]
File: maps
Comment 9 Michele 2015-02-27 16:31:14 UTC 
Created attachment 996113 [details]
File: open_fds
Comment 10 Michele 2015-02-27 16:31:15 UTC 
Created attachment 996114 [details]
File: proc_pid_status
Comment 11 Michele 2015-02-27 16:31:16 UTC 
Created attachment 996115 [details]
File: var_log_messages
Comment 12 Cole Robinson 2015-05-06 14:59:10 UTC 
*** Bug 1211571 has been marked as a duplicate of this bug. ***
Comment 13 Cole Robinson 2015-05-06 15:02:19 UTC 
Looked into this out of curiousity. signal_handler is:

static void
signal_handler(int signum)
{
    static gint recursion = FALSE;

    /*
     * reset all signal handlers: any further crashes should just be allowed
     * to crash normally.
     * */
    signal(SIGSEGV, segv_handler);
    signal(SIGABRT, abrt_handler);
    signal(SIGFPE,  fpe_handler);
    signal(SIGILL,  ill_handler);
#ifndef G_OS_WIN32  
    signal(SIGBUS,  bus_handler);
#endif

    /* Stop bizarre loops */
    if (recursion)
        abort ();

    recursion = TRUE;

    g_main_loop_quit(mainloop);
}


It's hitting the abort()... but the usage of signal handler is strange anyways. I don't know why it wants to catch SIGABRT etc, the only thing it seems to want to handle is SIGINT and SIGTERM

And you can't call any gtk functions from a signal handler, which may contribute to crashes here: http://askra.de/software/gtk-signals/x2992.html
Comment 14 Daniel Berrangé 2015-05-06 15:09:35 UTC 
(In reply to Cole Robinson from comment #13)
> And you can't call any gtk functions from a signal handler, which may
> contribute to crashes here: http://askra.de/software/gtk-signals/x2992.html

And if it doesn't crash, it is likely to deadlock, because g_main_loop_quit acquires mutexes, and that is not async signal safe.
Comment 15 Marc-Andre Lureau 2015-05-06 15:31:39 UTC 
That should fix it:
http://lists.freedesktop.org/archives/spice-devel/2015-May/019697.html
Comment 16 Marc-Andre Lureau 2015-06-29 23:38:27 UTC 
f22 should have spice-gtk 0.29 with the fixes now