2010/6/12 Guido Berhoerster <guido+sourceforge.net@berhoerster.name>
Looking at the last fix for catching signals on X server startup
I noticed that the signal handling is still flawed:

Only shared objects of type volatile sig_atomic_t can be safely
accessed and modified from within the signal handler,
lxcom_last_sig must be declared accordingly (also note that the
size of sig_atomic_t is implementation dependent).  I also think
this can be completely avoided if failing to start X quits lxdm
rather than continuously restarting it.

The current signal handler also still invokes several
non-async-safe functions, i.e. lxcom_raise_signal uses sprintf
and strlen, lxcom_write uses memset.

fixed, but I don't think memset is not signal safe
log_sigsegv is also problematic in this regard, I think
backtrace_symbols() is not async-safe (somebody correct me if I'm
wrong), lxdm_quit_self surely isn't, call _Exit or abort instead.

I think take infomation from SIGSEGV is better than just exit, we can't worse than it.
Apparently (from what i gather from the GDM source), the X server
needs SIGTTIN, SIGTTOU, and SIGUSR1 to be ignored.

I don't know SIGTTIN,SIGTTOU, as xserver's doc, SIGUSR1 is optional.
Any file operations after set_signal need to be protected against
non-fatal signal handling, i.e. errno needs to be checked for
EINTR and the operation if necessary repeated.

You don't check any return values when setting up signal

I'm not sure if you are aware that when you don't explicitly mask
other signals your signal handler might be interrupted by a
different signal.

Trying to setup a signal handler for SIGKILL is a nop, it cannot
be caught.

Guido Berhoerster