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

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.



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