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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
