<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - SalUserEventList::isFrameAlive hang after crash" href="https://bugs.documentfoundation.org/show_bug.cgi?id=133770#c27">Comment # 27</a> on <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - SalUserEventList::isFrameAlive hang after crash" href="https://bugs.documentfoundation.org/show_bug.cgi?id=133770">bug 133770</a> from <a class="email" href="mailto:glogow@fbihome.de" title="Jan-Marek Glogowski <glogow@fbihome.de>"> Jan-Marek Glogowski</a> <pre>I just checked desktop/win32/source/loader.cxx, the LO watchdog process. It only does a loop of MsgWaitForMultipleObjects(1, &aProcessInfo.hProcess, ...) and then calls GetExitCodeProcess. I guess the loop won't terminate, while the process is running and then we check the exit code to handle some LO specific exit codes for uncaught exceptions or a normal restart. Interestingly we don't check the return value from GetExitCodeProcess, so won't detect a case of STILL_ACTIVE. Maybe our watchdog is buggy? Can you check the pid to verify, if it's really the old process or a new one and it's actually a startup problem? Not that I yet tried to reproduce this. Just some curiosity. ---------- (In reply to Telesto from <a href="show_bug.cgi?id=133770#c26">comment #26</a>) ... > LibreOffice crashed storing recovery information now.. If a process has really crashed, you have no way to "storing recovery information". These are just saved in some interval, while everything is still ok. Maybe LO does some additional stuff for the "uncaught exception" case, but in any case the process state will be compromised, so no way to store anything useful (except for the process backtrace, if possible, but that's just a bonus for developers). P.S. I guess STR = Steps to Reproduce.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>