Bug 100184 - OpenGL-related crash upon exit
Summary: OpenGL-related crash upon exit
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.2.0.0.beta1
Hardware: All Windows (All)
: medium major
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:5.3.0 target:5.2.0.1
Keywords: haveBacktrace
Depends on:
Blocks: VCL-OpenGL
  Show dependency treegraph
 
Reported: 2016-06-02 07:41 UTC by Aron Budea
Modified: 2016-10-25 18:55 UTC (History)
5 users (show)

See Also:
Crash report or crash signature: ["ImplOpenGLTexture::DecreaseRefCount(int)"]


Attachments
OpenGL device log (317 bytes, text/plain)
2016-06-02 07:48 UTC, Aron Budea
Details
WinDbg backtrace (4.80 KB, text/plain)
2016-06-02 08:22 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2016-06-02 07:41:54 UTC
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.
Comment 1 Aron Budea 2016-06-02 07:48:09 UTC
Created attachment 125451 [details]
OpenGL device log
Comment 2 Aron Budea 2016-06-02 08:22:46 UTC
Created attachment 125452 [details]
WinDbg backtrace
Comment 3 Aron Budea 2016-06-02 08:25:14 UTC
The backtrace is of the crash that happens on exit, and is from beta1.
Not sure what's happening on first start...
Comment 4 Tor Lillqvist 2016-06-02 09:13:10 UTC
Yep, I see this too, in master, but sure, it would be in 5.2, too.
Comment 5 Commit Notification 2016-06-08 10:37:15 UTC
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.
Comment 6 Commit Notification 2016-06-08 13:55:25 UTC
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.
Comment 7 Tor Lillqvist 2016-06-08 15:37:30 UTC
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
Comment 8 Tor Lillqvist 2016-06-08 15:56:27 UTC
Hmm, in master, on the other hand, I can't reproduce the problem any longer. There I get no unhandled exception when exiting.
Comment 9 Aron Budea 2016-06-08 18:24:49 UTC
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.
Comment 10 Aron Budea 2016-06-08 21:42:21 UTC
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.
Comment 11 Tomaz Vajngerl 2016-06-09 00:38:28 UTC
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.
Comment 12 Tomaz Vajngerl 2016-06-09 01:30:34 UTC
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
Comment 13 Commit Notification 2016-06-09 08:23:43 UTC
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.
Comment 14 Tor Lillqvist 2016-06-09 08:58:20 UTC
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.
Comment 15 Aron Budea 2016-06-10 00:55:35 UTC
(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.
Comment 16 Markus Mohrhard 2016-06-14 13:12:30 UTC
(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.