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. --guy -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
