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). --guy --guy -- 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 open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
