ErrorF in SIGIO context

[Chase Douglas]

On 04/03/2012 11:57 PM, Christopher James Halse Rogers wrote:
> I've been getting SIGSEGVs in mieqEnqueue while valgrinding the server
> hoping to find the source of an Ubuntu crash bug (which doesn't appear
> to affect the upstream server).
> 
> Upon inspection, it was dying when trying to print the EQ overflowing
> message.  Digging down, ErrorF appears to end up calling a whole bunch
> of functions that aren't listed as signal-safe - sprintf (which is where
> the segfault happens under valgrind), strlen (!?), vsnprintf, fwrite,
> and fflush.
> 
> Some of those (hello, strlen!) should be signal safe under any
> reasonable implementation, but it seems that sprintf isn't, at least
> under valgrind.
> 
> Is my analysis correct?  What, if anything, should be done about this -
> it doesn't seem like anything's terribly broken when running X on glibc.

On my system, the only thing that caused a valgrind crash was the
sprintf to generate the timestamp at the beginning of a log message. The
quick fix is to format that piece of the message manually and write it
to the log fd directly.

However, I fear we will hit issues no matter what if we allow the use of
variadic arguments in log functions accessible in SIGIO context. We
can't guarantee that any *printf functions are signal safe, and we're
not going to reimplement *printf either :).

My proposal would be:

* When in signal context, ErrorF and such print a warning like "Warning:
Attempting to log message in signal context". Maybe we can also print
the format string itself, without the variadic argument replacement, so
a developer can grep for the message and fix it up.

* Provide a new function, ErrorSig(char *message), that manually formats
the timestamp and then prints the message directly in a completely
signal safe manner.

-- Chase