http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c10 --- Comment #10 from Guido Berhörster <guido+opensuse.org@berhoerster.name> 2010-05-22 10:02:42 UTC --- I'll summarize the signal handling a bit more. During initialization it first sets up an atexit(3) handler and after that signal handlers using signal(2). The signal handler for SIGINT and SIGTERM calls exit, thus triggering the exit handler which is then supposed to do the cleanup (mainly removing the g_child_watch handlers for the session, greeter, and X and killing them if they are still alive and closing the PAM session). This is fundamentally broken in multiple ways: * while on Linux signal seems to block further instances of the same signal from being delivered, this is not portable and since it uses the same signal handlers for SIGINT and SIGTERM, the handler might be interrupted and recursively called * this is a problem since the handler itself is non-reentrant because it uses non-async-safe, non-reentrant glib and pam functions and the signal can be delivered at any time while building the UI, setting up PAM etc., which means that e.g. my call to g_source_remove to prevent the child watch handler from being triggered when killing the session might produce something completely unexpected because the glib's data structures on the heap are in an unpredictable state * not even exit(3) is according to signal(7) async-safe So my bandaid patch might mitigate the race condition there are many possibilities for races and crashes in the signal-handling code. While I'm not an expert on this I still conclude that there seems to be a complete lack of understanding on this upstream which makes me feel very uncomfortable. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.