With the second half of bug 100184 resolved, only the first crash remains. It's a "hidden" crash, LibreOffice recovers, but there's an (empty) Document Recovery dialog, and the crash reporter also activates.
-delete user profile
=> possible result 1: Writer starts fine, UI render is default => rinse and repeat from start (this happens very rarely for me, usually on the second try I get the crash)
=> possible result 2: after splash screen, an empty LibreOfficeDev Document Recovery dialog is shown
-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
This one doesn't seem to be directly related to OpenGL, maybe to the sidebar instead. There's no crash if the main application is run, only when Writer/Calc/etc. is started.
However, if there's no crash, UI render is always default, and if there is a crash, it's always GL. So it might still be connected to GL somehow.
OS: Windows 7, x64
LO version: 126.96.36.199.beta2, x86
Stuart -> Aron,
When you are starting Writer, is that from command window swriter.exe--or via a shortcut?
And for clarity, do you have different behavior if you open soffice.exe from command line or its shortcut?
Is there a difference in what is launched (without an existing profile), or was it just your STR was with a Writer launch?
I'm generally starting it from Start menu.
However, I tried with 'soffice.exe --writer' just now, and the result was the same (for some reason again the first run was fine, but after I did it again - after deleting the profile both times - I got the crash).
I'm not sure I understand the last question correctly. Does this answer your question? "There's no crash if the main application is run, only when Writer/Calc/etc. is started."
So, I tried with different applications, but if you meant something else, please clarify.
Created attachment 125589 [details]
WinDbg stacktrace of 5.2.0b2 crash report
On Windows 10 Pro 64-bit en-US with nVidia GTX-750i GPU
Version: 188.8.131.52.beta2 (x64)
Build ID: ae12e6f168ba39f137fc110174a37c482ce68fa4
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default;
Locale: en-US (en_US)
Using swriter.exe, with install directory on path (sorry for not being clear, was the launch via soffice.exe & StartCenter or direct with swriter.exe) have the issue.
Launching with no profile into simpress.exe, scalc.exe, sdraw.exe--close without fully opening the GUI--and the user profile is partial.
While smath.exe and soffice.exe seem to come up cleanly, and profile has OpenGL enabled.
If launched from StartCenter, a launch of Writer closes, and on relaunch see the error report dialog, and after that Writer opens with default rendering.
So kind of seems like this is OpenGL test related as well.
Adding regression-related tags, since this was working in 5.1.
Tomaz: noticing vcl/opengl/texture.cxx in bt, thought you might be interested in this one.
Seems like the same problem as with 100184. The whole fix didn't get into LO 5.2 beta2, so please check the LO 5.2 daily build after beta2 (if there is one available).
So, with todays beta2+ build on Windows 8.1 Ent 64-bit
Version: 184.108.40.206.beta2+ (x64)
Build ID: 32ecf73b9f26e74f72086bf43a72244c165a391c
CPU Threads: 8; OS Version: Windows 6.29; UI Render: default;
TinderBox: Win-x86_64@62-TDF, Branch:libreoffice-5-2, Time: 2016-06-14_11:55:59
Locale: en-US (en_US)
Still getting crash on initial launch and a truncated registrymodifications.xcu. Attaching WinDbg stack trace of hang launching swriter.exe (Task Manager -> dump soffice.bin process).
If I launch into smath.exe first, I get a full registry .xcu, where I can disable OpenGL rendering. And then get clean launch of other modules.
Created attachment 125656 [details]
WinDbg stackTrace crash in LO5.2.0b2+ launching Writer
Could you attach the opengl_device.log produced?
Created attachment 125800 [details]
OpenGL device log Win8.1 Ent with LO5.2.0beta2+ 20160614 build
the requested opengl_device.log
Created attachment 125801 [details]
OpenGL device log Win10 Pro with LO5.2.0beta2+ 20160614 build
same findings on a Windows 10 Pro 64-bit install, OpenGL log attached.
1. /a administrative install of libreoffice-5-2~2016-06-14_11.55.59_LibreOfficeDev_220.127.116.11.beta2_Win_x64_helppack_en-US.msi and help
2. configure UserInstallation from program/bootstrap.ini to $ORIGIN/../Data/settings
3. navigate to program
4. launch swriter.exe (command line or Explorer)
new profile with fully formed registrymodifications.xcu, and a session of Writer open.
profile is truncated, Writer closes
5. launch swriter.exe again
crash on launch
Writer opens, about dialog shows OpenGL renderer, profile is more complete including Recovery/RecoveryList and RecoveryInfo, but--*there are no common/VCL UseOpenGL or ForceOpenGL stanzas*-- which seems wrong (or has it been changed to not write the stanzas to registry).
6. disable OpenGL rendering (Tools -> Options -> View)
7. close Writer --UseOpenGL and ForceOpenGL stanzas set FALSE *are* written to registry--
8. launch Writer, verify rendering is Default
9. enable OpenGL (Tools -> Options -> View)
10. close Writer --the registry UseOpenGL stanza shows TRUE
11. no subsequent crashes.
First impressions with 18.104.22.168.
There's a clear-cut crash now upon first start, or if it's been in GL mode, and hasn't been started in a while (not very exact, but that's how it is). After crash the program has to be started again, and it starts with default rendering. Crash reporter isn't triggered.
This seems to be the same as bug 100487, except that is observed with a dbgutil master build. See my comments there for some observations.
(In reply to Aron Budea from comment #12)
> First impressions with 22.214.171.124.
> There's a clear-cut crash now upon first start, or if it's been in GL mode,
> and hasn't been started in a while (not very exact, but that's how it is).
> After crash the program has to be started again, and it starts with default
> rendering. Crash reporter isn't triggered.
> This seems to be the same as bug 100487, except that is observed with a
> dbgutil master build. See my comments there for some observations.
You mention 126.96.36.199 and master here and it is not obvious which parts are related to master and what is related to the RC.
(In reply to Markus Mohrhard from comment #13)
> You mention 188.8.131.52 and master here and it is not obvious which parts are
> related to master and what is related to the RC.
Sorry, this bug report is entirely for 5.2. The other one (bug 100487) is for master. My hunch is they are at least partially the same issue.
Still occurs in 184.108.40.206.
Can we set this to component LibreOffice?
Sure. Can't remember why I used framework there, must've been a mistake.
Two days ago, I had the same experience. sWriter crashes. I've made a new userprofile and the problem is gone. But then I made one change, I pinned the Navigator. And yes, on the next start, LO crashes. I then released the Navigator and the problem is gone.
Sorry, I forgot to tell you that I did it with LO 220.127.116.11 on Windows7.
I guess this regression can be bibisected now with the latest win repositories. More info: https://wiki.documentfoundation.org/QA/Bibisect/Windows#Versions
Adding keyword 'bibisectRequest'
Hi raal, one for you?
No crash in 18.104.22.168 anymore. Not sure if it's completely fixed, but this bug is still very likely a duplicate of bug 102295.
*** This bug has been marked as a duplicate of bug 102295 ***