Ulrich Windl wrote:
> 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

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).



You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to