Flush pending messages to disk on fatal message #278
Conversation
|
I guess if we're feeling brave we can intercept the SIGSEGV signal during the lifetime of the logger and use it to flush pending logging messages in the case that immediate mode is not selected. I really don't want to do this though. |
|
This still needs some work. Thinking about it, makeLog shouldn't be used as it depends on a queued connection, and so the fatal message wouldn't be queued by the time pending messages are flushed. I'll get to this in the morning. |
|
While you're at it, you could rename the |
924dfb4 to
ad3cd53
Compare
|
Fixed.
Done. |
Also flush any pending messages to the log file. Most users on Windows would not see the pending message dump on stderr, and depend on the file to retrieve the log. This may make fatal errors reported by qFatal more complete. However, if the logs are not set to immediate mode and a segfault happens between dumps to disk, messages will still get missed. To do this, we reword the qt message handler to file the fatal log message normally, so that it will get picked up by the final message dump, for both file and console. And change the fatalMessage procedure call into a blocking call on the log thread, so that we aren't trying to dump pendingMessages while the log thread is writing to it... hopefully the application is still in a good enough state to do blocking calls. Because the fatalMessage handler is now in the log thread where it should be, it can empty the pending message queue so that these messages won't be written twice before the application quits.
Update translations and ui files with the new string. It appears that Qt also decided to shuffle some xml nodes around in the ui file, even though it doesn't change anything.
Use proper SI unit representation for milliseconds. While I'm here, add note about using no delay for testing.
ad3cd53 to
cab1cb6
Compare
|
Ok that should be it for real this time. I thought of a last-minute bug an hour after I've pushed. (the need to empty the pending message queue). Sorry for the mail spam. |
|
It works fine with qFatal. 👍 |
Do you mean that there would be side effects? I've written some code to do that and it doesn't seem to affect the stack trace. |
This ensures all messages get written to the log file on segmentation fault. Idea from mpc-qt#278.
Well that's good. I thought we might have to think about using libbacktrace to create the traces ourselves. |
This ensures all messages get written to the log file on segmentation fault. Idea from mpc-qt#278.
Also flush any pending messages to the log file. Most users on Windows would not see the pending message dump on stderr, and depend on the file to retrieve the log. This may make fatal errors reported by qFatal more complete. However, if the logs are not set to immediate mode and a segfault happens between dumps to disk, messages will still get missed.
Change "Window update interval" to "Update interval" to indicate that it applies across the board. Change update interval suffix from "msec" to "ms". Indicate that "No interval" should be used during testing.