<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body>
<p>
<div>
<b><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#c28">Comment # 28</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 <span class="vcard"><a class="email" href="mailto:telesto@surfxs.nl" title="Telesto <telesto@surfxs.nl>"> <span class="fn">Telesto</span></a>
</span></b>
<pre>Created <span class=""><a href="http://bugs.documentfoundation.org/attachment.cgi?id=167918" name="attach_167918" title="Screenshot Document Recovery">attachment 167918</a> <a href="http://bugs.documentfoundation.org/attachment.cgi?id=167918&action=edit" title="Screenshot Document Recovery">[details]</a></span>
Screenshot Document Recovery
(In reply to Jan-Marek Glogowski from <a href="show_bug.cgi?id=133770#c27">comment #27</a>)
<span class="quote">> 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.</span >
A) See screenshot What I mean with Document Recovery Windows with "graceful"
crash. Instead of abruptly terminating..
Off-topic Note: Still not seeing the whole point of that dialog (but really of
off topic)
* it manages to crash again while saving the recovery info in number of cases..
mostly if the crash is caused by rendering/layout flaw. Kind of hard to keep
showcases if this.. people tend to fix the layout flaws (so you never reach the
crash of the recovery dialog; so kind of masked). Also speculating this causing
lovely recovery issues...
* it turns up in 40% of the cases or so (again depending on crasher). The other
60% it simply skips it: the lovely abrupt termination..
--
B) It's the old process not exiting.. (did check pid specifically, but I memory
usage 600 mb to different from new started process..
C) The screenshot is based on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Crash after undo/redo dance (but broken before. Selecting doesn't cut image frame)"
href="show_bug.cgi?id=138718">bug 138718</a> (which also illustrated the 'deadlock'
or whatever is happening). Or I'm I the only one encountering this on my
Windows 8.1 system? FWIW: as said the first time crash working properly..
failure when doing same thing again (so only the second and following runs).
After reboot everything is back to normal, until the second crash. It isn't my
user profile.. nor limited to specific LibO version.. 7.0 branch and up, I
think (but maybe even 6.4?)</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>