LO 5.2 beta1, x86/Windows 7 x64 Prerequisite: empty user profile. Upon starting Writer, I get an empty LibreOfficeDev Document Recovery dialog, then crash reporter is opened (it doesn't work, but that's a different thing), and finally I end up in the central launcher. Upon exiting with [X] I get a crash ("LibreOfficeDev has stopped working"). Once the profile exists, switching between GL/default in "Tools -> Options... -> LibreOfficeDev -> View -> Use OpenGL for all rendering (on restart)" also often produces crashes, sometimes on exit, sometimes on start. With master build (7a2bca302f8299d70f77952110fb4ccfa4b258c2), empty user profile: Writer starts up with GL enabled, crash upon exit. GL is disabled upon next start. Switching on GL works, starts up with GL enabled, but again, crashes upon exit, and GL is disabled upon next start, and thus the circle is complete.
Created attachment 125451 [details] OpenGL device log
Created attachment 125452 [details] WinDbg backtrace
The backtrace is of the crash that happens on exit, and is from beta1. Not sure what's happening on first start...
Yep, I see this too, in master, but sure, it would be in 5.2, too.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8dcf60ecbe9c159831ece3b6201882f1d0033472 tdf#100184 fix the lifecycle of a texture in an atlas It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6efb6fa31270adc84b5884cd4a84e1a3296d535d&h=libreoffice-5-2 tdf#100184 fix the lifecycle of a texture in an atlas It will be available in 5.2.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Unfortunately that commit did not seem to fix the problem. In 5.2, for which I happen to have a fresh build with the above commit, I still get a exception when exiting, that gets handled by the VCLExceptionSignal_impl(). A SAL_DEBUG_TRACE() there produces this backtrace which sadly doesn't seem very useful: debug:7936:6912: ====> VCLExceptionSignal_impl at: 8: osl_backtraceAsString - 0x6e24f710 7: `anonymous namespace'::log - 0x6e21d1f0 6: sal_detail_log - 0x6e21d820 5: VCLExceptionSignal_impl - 0x6ad70830 4: callSignalHandler - 0x6e21d8b0 3: `anonymous namespace'::signalHandlerFunction - 0x6e267e60 2: UnhandledExceptionFilter - 0x7689f320 1: LdrSetAppCompatDllRedirectionCallback - 0x76fabb00 0: RtlUnicodeStringToInteger - 0x76f85b90 and the VCLExceptionSignal_impl() then calls OpenGLZone::hardDisable(). If I instead attach soffice.bin to VS, and exit LO, VS catches an unhandled exception 0xC0000005: Access violation reading location 0xDDDDDDE5. Its backtrace: > vcllo.dll!std::vector<int,std::allocator<int> >::size() Line 1148 C++ vcllo.dll!ImplOpenGLTexture::DecreaseRefCount(int nSlotNumber) Line 246 C++ vcllo.dll!OpenGLTexture::operator=(const OpenGLTexture & rTexture) Line 591 C++ vcllo.dll!OpenGLSalBitmap::Destroy() Line 244 C++ vcllo.dll!OpenGLSalBitmap::~OpenGLSalBitmap() Line 125 C++ vcllo.dll!OpenGLSalBitmap::`scalar deleting destructor'(unsigned int) C++ vcllo.dll!ImpBitmap::~ImpBitmap() Line 39 C++ vcllo.dll!ImpBitmap::`scalar deleting destructor'(unsigned int) C++ vcllo.dll!std::_Ref_count<ImpBitmap>::_Destroy() Line 159 C++ vcllo.dll!std::_Ref_count_base::_Decref() Line 119 C++ vcllo.dll!std::_Ptr_base<ImpBitmap>::_Decref() Line 344 C++ vcllo.dll!std::shared_ptr<ImpBitmap>::~shared_ptr<ImpBitmap>() Line 611 C++ vcllo.dll!Bitmap::~Bitmap() Line 126 C++ vcllo.dll!BitmapEx::~BitmapEx() Line 188 C++ vcllo.dll!std::pair<bool,BitmapEx>::~pair<bool,BitmapEx>() C++ vcllo.dll!std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> >::~pair<rtl::OUString const ,std::pair<bool,BitmapEx> >() C++ vcllo.dll!std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> >::`scalar deleting destructor'(unsigned int) C++ vcllo.dll!std::allocator<std::_List_node<std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> >,void *> >::destroy<std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> > >(std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> > * _Ptr) Line 608 C++ vcllo.dll!std::allocator_traits<std::allocator<std::_List_node<std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> >,void *> > >::destroy<std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> > >(std::allocator<std::_List_node<std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> >,void *> > & _Al, std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> > * _Ptr) Line 731 C++ vcllo.dll!std::_Wrap_alloc<std::allocator<std::_List_node<std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> >,void *> > >::destroy<std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> > >(std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> > * _Ptr) Line 879 C++ vcllo.dll!std::_List_buy<std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> >,std::allocator<std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> > > >::_Freenode(std::_List_node<std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> >,void *> * _Pnode) Line 853 C++ vcllo.dll!std::list<std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> >,std::allocator<std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> > > >::clear() Line 1505 C++ vcllo.dll!std::_Hash<std::_Umap_traits<rtl::OUString,std::pair<bool,BitmapEx>,std::_Uhash_compare<rtl::OUString,rtl::OUStringHash,std::equal_to<rtl::OUString> >,std::allocator<std::pair<rtl::OUString const ,std::pair<bool,BitmapEx> > >,0> >::clear() Line 718 C++ vcllo.dll!ImplImageTree::shutDown() Line 268 C++ vcllo.dll!DeInitVCL() Line 394 C++ vcllo.dll!ImplSVMain() Line 204 C++ vcllo.dll!SVMain() Line 214 C++ sofficeapp.dll!soffice_main() Line 165 C++ soffice.bin!sal_main() Line 48 C soffice.bin!main(int argc, char * * argv) Line 47 C
Hmm, in master, on the other hand, I can't reproduce the problem any longer. There I get no unhandled exception when exiting.
Note that I'm still getting those weird crashes upon start as well (with 5.2 beta2). I chose the title of my bug report for a reason. CCing Markus, so he knows that the crash reports I'm uploading are related to this.
These are the steps I take. There are two different crashes, see linked crash reports (thanks, Markus :)). -delete user profile -start Writer => possible result 1: Writer starts fine, UI render is default => rinse and repeat from start => possible result 2: splash screen shows, very briefly disappears and reappears, then empty LibreOfficeDev Document Recovery dialog is shown -press OK -Crash Report dialog appears, press Send Crash Report ( http://crashreport.libreoffice.org/stats/crash_details/b9ee7997-479b-47fa-8cea-c725dcc28f72 ), then Close -LibreOfficeDev main application appears, UI render is GL -Exit => crash (LibreOfficeDev has stopped working etc.) -on next start Crash Report dialog appears, press Send Crash Report ( http://crashreport.libreoffice.org/stats/crash_details/820f75cf-3df2-4c87-a0ab-9fcf7f2d4377 <= same crash as in the attached backtrace, this is what's been discussed so far), then Close -LibreOfficeDev main application appears, UI render is default.
Maybe I made a mistake when backporting to 5.2 or I missed something. I'll check today.Maybe I made a mistake when backporting to 5.2 or I missed something. I'll check today.
Indeed, changes to FixedTextureAtlas aren't present in 5-2 but they are in master. I must have missed the file when cherry-picking and rebasing. I have added them back in [1]. [1] https://gerrit.libreoffice.org/26080
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3217029eaf355ee059dc4d371cf1e65c346405dd&h=libreoffice-5-2 tdf#100184 add missing changes to FixedTextureAtlas It will be available in 5.2.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I am not sure how this exception that was handled in VCLExceptionSignal_impl even showed up to the user, and was reported? At least for me, what I saw was this: I start LibreOffice with an empty user profile (no instdir/cache, instdir/user, or \Users\Tor\AppData\Roaming\LibreOffice). It uses OpenGL, and works fine. Without doing anything special, I exit LibreOffice. I see no error messages or anything. (The exit just take a bit longer that expected, a few seconds, but this is noticeable only when running soffice.exe from the command-line of course.) Next time I start LibreOffice, it does not use OpenGL. *That* was the problem I was having, that OpenGL was mysteriously turned off for no apparent reason, with no warning or error message at all. Digging deeper then showed that an exception happened during exiting and this VCLExceptionSignal_impl was invoked that turned off OpenGL. So I wonder how Aron here even saw any indication of a crash? Or is it so that if I would have actually had a document open when exiting, I would have seen error messages? Anyway, whatever, the stack trace provided *does* match that which I saw when the exception hit, so probably best to resolve this as fixed.
(In reply to Tor Lillqvist from comment #14) > So I wonder how Aron here even saw any indication of a crash? Or is it so > that if I would have actually had a document open when exiting, I would have > seen error messages? I had no document open upon exit. I still have the aforementioned dbgutil build from master when it was still exhibiting this behavior (~2 weeks ago), is there anything useful I could check about this inexplicably showing crash? (for me, this crash never got suppressed, unlike the crash at the start, for which I now opened bug 100300) Tor, Tomaz, thanks for looking into this, and for the fix! I'll verify it when RC1 comes.
(In reply to Tor Lillqvist from comment #14) > I am not sure how this exception that was handled in VCLExceptionSignal_impl > even showed up to the user, and was reported? At least for me, what I saw > was this: > > I start LibreOffice with an empty user profile (no instdir/cache, > instdir/user, or \Users\Tor\AppData\Roaming\LibreOffice). It uses OpenGL, > and works fine. Without doing anything special, I exit LibreOffice. I see no > error messages or anything. (The exit just take a bit longer that expected, > a few seconds, but this is noticeable only when running soffice.exe from the > command-line of course.) > > Next time I start LibreOffice, it does not use OpenGL. > > *That* was the problem I was having, that OpenGL was mysteriously turned off > for no apparent reason, with no warning or error message at all. Digging > deeper then showed that an exception happened during exiting and this > VCLExceptionSignal_impl was invoked that turned off OpenGL. > > So I wonder how Aron here even saw any indication of a crash? Or is it so > that if I would have actually had a document open when exiting, I would have > seen error messages? > > Anyway, whatever, the stack trace provided *does* match that which I saw > when the exception hit, so probably best to resolve this as fixed. The crash reporting most likely created a minidump and told him during the next start-up that we crashed. One of our signal handlers automatically deactivates OpenGL if the crash happened while the OpenGLWatchdog was active. So at least if we crash now even during shut down the user should always get a notification during the next start that we crashed and ask him to upload the crash report. We could and most likely should of course add a note in the crash report that this happened in an OpenGL code path. The current UseOpenGL flag just tells us that OpenGL was activated at all and not if we crashed during an OpenGL part.