[PATCH] do NOT perform illegal operations in a SIGSEGV handler

[guy keren]

if you get SIGSEGV - most likely we have some memory ocrruption - so
catching this signal, flushing the log and then returning (letting the
process continue execution) is a big no-no.

Signed-off-by: guy keren <ch...@actcom.co.il>

--guy

[Ulrich Windl]

On 22 Nov 2009 at 13:50, guy keren wrote:

>
> if you get SIGSEGV - most likely we have some memory ocrruption - so
> catching this signal, flushing the log and then returning (letting the
> process continue execution) is a big no-no.

Well,

depending on buffering, flushing the log may be a good idea. The question whethet
it's safe to continue is a valid one, however. You could abort after that. Maybe
it's better to ensure htat the logs are flushed frequent enough, so you don't need
this. (I haven't checked)

Ulrich

[guy keren]

The idea is that once your program receives a SEGV signal - you cannot
be sure why it happened. it could have happened because the memory used
by the logger contained a dangling pointer - and then trying to print
the log from the SEGV handler could result an endless loop. the least
you could do is set SIGSEGV to ignore before printing the log - although
i am not sure that invoking a system call from within a signal handler
is a good idea to begin with.

by the way - if the system is set to generate core files for daemons,
then at least in theory it is possible to write some gdb macros that
will extract the non-flushed part of the logs from the core file -
assuming the shared-memory segment is still available. i need to check
if it's possible to make gdb re-attach to that segment while handling
the core file (generally this is not possible since you cannot run
function without attaching to a running process. however - there's a
project that allows re-creating a process around a core file - and
perhaps using that project this will become possible).

--guy
--guy

[Ulrich Windl]

On 24 Nov 2009 at 13:20, guy keren wrote:

[...]

> by the way - if the system is set to generate core files for daemons,
> then at least in theory it is possible to write some gdb macros that
> will extract the non-flushed part of the logs from the core file -
> assuming the shared-memory segment is still available. i need to check
> if it's possible to make gdb re-attach to that segment while handling
> the core file (generally this is not possible since you cannot run
> function without attaching to a running process. however - there's a
> project that allows re-creating a process around a core file - and
> perhaps using that project this will become possible).
>

From my eperience, it's much easier for users to find the last lines in a log
file, rather than find a core dump file. Not to talk about corelating the core
file with a program plus doing something useful with it.

I a program I wrote years ago I did this: The log handler did flush the log
whenever an error or more important had been output; it did not flush the log for
debug messages or similar (I had fatal errors, errors, warnings, informational
messages, and debug messages). Assuming that the program will crash only after
some problem had been detected, this might help.

Regards,
Ulrich

[guy keren]

and then you risk that the program will not be able to terminate in
specific corruption cases. so the question is - what is deemed more
important - that the program will terminate in case of a SIGSEGV, or
that it'll emit the remains of the logs for the price of a (small?)
chance of getting stuck during this attempt.

i don't really know what is the "right" answer.

--guy

[Mike Christie]

Does anyone else have an opinion on this issue?