Bug Hunting Session
Bug 98365 - Crash on first run of 64-bit build with no user profile
Summary: Crash on first run of 64-bit build with no user profile
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha0+
Hardware: All Windows (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace
Depends on:
Blocks: VCL-OpenGL User-Profile
  Show dependency treegraph
 
Reported: 2016-03-02 22:32 UTC by Yousuf Philips (jay) (retired)
Modified: 2017-06-25 23:03 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
opengl_device.log (332 bytes, text/plain)
2016-03-22 07:23 UTC, Yousuf Philips (jay) (retired)
Details
windbg (10.32 KB, text/plain)
2016-03-22 21:48 UTC, Yousuf Philips (jay) (retired)
Details
windbg2 (17.88 KB, text/plain)
2016-03-22 22:20 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2016-03-02 22:32:24 UTC
Steps:
1) Install Windows x64 build
2) Clear the user profile if one already exists
3) Open LibreOffice
4) Crash

The crash doesnt happen a second time around.

Version: 5.1.1.1 (x64)
Build ID: c43cb650e9c145b181321ea547d38296db70f36e
CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; 
Locale: en-US (en_US)

I tried to capture the backtrace, but this is all i got.

CommandLine: E:\LibreOffice\5.1x64\program\soffice.exe
Symbol search path is: CACHE*C:\symbols;SRV*http://dev-builds.libreoffice.org/daily/master/Win-x86@39/symbols;SRV*http://dev-downloads.libreoffice.org/symstore/symbols;SRV*http://msdl.microsoft.com/download/symbols
Executable search path is: 
ModLoad: 00000001`3fa90000 00000001`3faa2000   soffice.exe
ModLoad: 00000000`77b90000 00000000`77d39000   ntdll.dll
ModLoad: 00000000`77970000 00000000`77a8f000   C:\Windows\system32\kernel32.dll
ModLoad: 000007fe`fdb70000 000007fe`fdbdc000   C:\Windows\system32\KERNELBASE.dll
ModLoad: 000007fe`ff620000 000007fe`ff6fb000   C:\Windows\system32\ADVAPI32.dll
ModLoad: 000007fe`fded0000 000007fe`fdf6f000   C:\Windows\system32\msvcrt.dll
ModLoad: 000007fe`ff080000 000007fe`ff09f000   C:\Windows\SYSTEM32\sechost.dll
ModLoad: 000007fe`ff280000 000007fe`ff3ad000   C:\Windows\system32\RPCRT4.dll
ModLoad: 000007fe`fe040000 000007fe`fedc8000   C:\Windows\system32\SHELL32.dll
ModLoad: 000007fe`fee00000 000007fe`fee71000   C:\Windows\system32\SHLWAPI.dll
ModLoad: 000007fe`ff5b0000 000007fe`ff617000   C:\Windows\system32\GDI32.dll
ModLoad: 00000000`77a90000 00000000`77b8a000   C:\Windows\system32\USER32.dll
ModLoad: 000007fe`fde60000 000007fe`fde6e000   C:\Windows\system32\LPK.dll
ModLoad: 000007fe`fdf70000 000007fe`fe039000   C:\Windows\system32\USP10.dll
ModLoad: 000007fe`fa890000 000007fe`fa97f000   C:\Windows\system32\MSVCR120.dll
(ed0.ee0): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00000000`77c3cb70 cc              int     3
0:000> g
ModLoad: 000007fe`fedd0000 000007fe`fedfe000   C:\Windows\system32\IMM32.DLL
ModLoad: 000007fe`ff400000 000007fe`ff509000   C:\Windows\system32\MSCTF.dll
ModLoad: 000007fe`fd800000 000007fe`fd857000   C:\Windows\system32\apphelp.dll
ntdll!ZwTerminateProcess+0xa:
00000000`77be157a c3              ret
0:000> !analyze -v
Last event: ed0.ee0: Exit process 0:ed0, code 0
  debugger time: Thu Mar  3 02:05:47.364 2016 (UTC + 4:00)
Comment 1 Maxim Monastirsky 2016-03-02 23:01:38 UTC
What happens if you force OpenGL and restart? Does it crash then too? If yes - it's the well known first-time OpenGL crash. (If the system doesn't have proper GL support and it crashes, then OpenGL is disabled for the next time.)
Comment 2 Yousuf Philips (jay) (retired) 2016-03-03 01:57:24 UTC
(In reply to Maxim Monastirsky from comment #1)
> What happens if you force OpenGL and restart? Does it crash then too? If yes
> - it's the well known first-time OpenGL crash. (If the system doesn't have
> proper GL support and it crashes, then OpenGL is disabled for the next time.)

Yes it does crash. But why does this crash only happen on x64 build, as it doesnt happen when i use a x86 build with no profile.
Comment 3 Buovjaga 2016-03-21 19:35:11 UTC
Can you give C:\Users\User\AppData\Roaming\LibreOffice dev\4\cache\opengl_device.log
Comment 4 Yousuf Philips (jay) (retired) 2016-03-22 07:21:03 UTC
(In reply to Maxim Monastirsky from comment #1)
> If yes - it's the well known first-time OpenGL crash.

Is there a bug report for this issue?
Comment 5 Yousuf Philips (jay) (retired) 2016-03-22 07:23:06 UTC
Created attachment 123764 [details]
opengl_device.log

(In reply to Buovjaga from comment #3)
> Can you give C:\Users\User\AppData\Roaming\LibreOffice
> dev\4\cache\opengl_device.log

Here you go. My graphics card only supports OpenGL 1.4, which is to low to render the UI.
Comment 6 Maxim Monastirsky 2016-03-22 21:08:21 UTC
(In reply to Yousuf (Jay) Philips from comment #0)
> I tried to capture the backtrace, but this is all i got.
> 
> CommandLine: E:\LibreOffice\5.1x64\program\soffice.exe
...
> ntdll!ZwTerminateProcess+0xa:
> 00000000`77be157a c3              ret
> 0:000> !analyze -v
> Last event: ed0.ee0: Exit process 0:ed0, code 0
>   debugger time: Thu Mar  3 02:05:47.364 2016 (UTC + 4:00)

It looks like you attached to soffice.exe, but you should actually attach to soffice.bin. Could you try this?

(In reply to Yousuf (Jay) Philips from comment #4)
> Is there a bug report for this issue?
Can't find it right now, but I remember I saw it mentioned somewhere.
Comment 7 Yousuf Philips (jay) (retired) 2016-03-22 21:48:39 UTC
Created attachment 123780 [details]
windbg

(In reply to Maxim Monastirsky from comment #6)
> It looks like you attached to soffice.exe, but you should actually attach to
> soffice.bin. Could you try this?

Here's another try.
Comment 8 Yousuf Philips (jay) (retired) 2016-03-22 22:20:27 UTC
Created attachment 123781 [details]
windbg2

i assume this backtrace is better.
Comment 9 Aron Budea 2016-05-19 04:28:45 UTC
I'm getting this in 5.1.3.2. Not sure if it's the same crash, but it occurs under the exact same circumstances as reported here: in x64 build with deleted profile.
Even then it doesn't occur every time, but it's been happening regularly.
Comment 10 Yousuf Philips (jay) (retired) 2016-05-19 06:52:11 UTC
@Meeks: Can you check my backtrace for this first startup crash for windows x64?
Comment 11 Michael Meeks 2016-05-30 13:14:24 UTC
Hi Jay - so - you sure this is a crash ? ultimately your GL device looks like it should be black-listed so there should be no GL in-use.

When we do the first-ever start; on some platforms it is expected that the first run installs and initializes extensions and then the main binary exits with a given return code and should be re-started by the wrapper =) [ at least this used to be the case left & right ].

Whether that happens via ZwTerminateProcess I forget =) perhaps not - but ... then again - this trace:

https://bug-attachments.documentfoundation.org/attachment.cgi?id=123781

does indeed show some GL crash / badness. Can you confirm you generated that trace with this device:

https://bug-attachments.documentfoundation.org/attachment.cgi?id=123764

because at least my master blacklist has:

    <blacklist>
        <entry os="all" vendor="intel" compare="less" version="10.18.14.4264">
            <device id="all"/>
        </entry>

Which should knock out your intel 8.15.10.1930 driver ... very strange.

Thanks !
Comment 12 Yousuf Philips (jay) (retired) 2016-05-31 12:05:12 UTC
(In reply to Michael Meeks from comment #11)
> Hi Jay - so - you sure this is a crash ? ultimately your GL device looks
> like it should be black-listed so there should be no GL in-use.

Hi Michael, yes sure.

> When we do the first-ever start; on some platforms it is expected that the
> first run installs and initializes extensions and then the main binary exits
> with a given return code and should be re-started by the wrapper =) [ at
> least this used to be the case left & right ].
> 
> Whether that happens via ZwTerminateProcess I forget =) perhaps not - but
> ... then again - this trace:
> 
> https://bug-attachments.documentfoundation.org/attachment.cgi?id=123781
> 
> does indeed show some GL crash / badness. Can you confirm you generated that
> trace with this device:
> 
> https://bug-attachments.documentfoundation.org/attachment.cgi?id=123764

Yes i only run windows 7 on my laptop, which is where this crash report came from.

> because at least my master blacklist has:
> 
>     <blacklist>
>         <entry os="all" vendor="intel" compare="less"
> version="10.18.14.4264">
>             <device id="all"/>
>         </entry>
> 
> Which should knock out your intel 8.15.10.1930 driver ... very strange.

Yes this is quite strange to me as this same thing doesnt happen on the x86 build.
Comment 13 Aron Budea 2016-06-20 04:23:30 UTC
I might be encountering a slightly different version of this issue in master, but can't say for sure. Nevertheless, I opened bug 100487 on that, any hints are welcome.
Comment 14 Julien Nabet 2016-09-29 19:28:42 UTC
Is it better thanks to this?
https://cgit.freedesktop.org/libreoffice/core/commit/?id=c9b2af045acc92c8665a8523407f530cc691d5bf

+        <entry os="7" vendor="intel">
+            <device id="all"/>
+        </entry>

See tdf#101138
Comment 15 Michael Meeks 2016-10-11 09:20:23 UTC
Intel/GL - their windows / GL driver quality is something awful before that date I suspect. It is also quite possible/probable that the 64bit drivers are worse than the 32bit ones ;-) 

Having said that - as Julien says - if you're running Windows 7 + Intel - the driver should be black-listed by -

commit 97fb2a8a43f11dba7c3e82380589b2334d09865a
Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Date:   Tue Jul 26 16:21:13 2016 +0900

    tdf#101138 opengl: blacklist intel drivers for Win 7

So is this still an issue in a recent 5.1.x ? I'd hope not -> marking fixed. Please re-open if you can reproduce with a recent 5.1.x

Thanks !