Bug 99258 - Windows builds of master 5.2.0alpha1+ failing in Extension Manager on launch
Summary: Windows builds of master 5.2.0alpha1+ failing in Extension Manager on launch
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha0+
Hardware: All Windows (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0 target:5.1.4
Keywords: regression
: 99309 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-04-13 04:00 UTC by V Stuart Foote
Modified: 2016-10-25 19:02 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
xcu file generated by version 5.2 Alpha1 (458 bytes, text/plain)
2016-04-26 21:43 UTC, Pedro
Details
XCU file generated by 5.2 Master daily build from TB#39 (OK) (1.61 KB, text/plain)
2016-04-26 21:45 UTC, Pedro
Details
Screenshot of Fatal Error (6.93 KB, image/png)
2016-04-30 02:04 UTC, Luke
Details
1st attempt to backtrace (3.46 KB, text/plain)
2016-04-30 02:09 UTC, Luke
Details
Backtrace of non-starting LO 5.2 Alpha1 under Windows 10 (8.71 KB, text/plain)
2016-04-30 03:22 UTC, Pedro
Details
WinDbg x86 stacktrace with symbols on Windows 10 (31.10 KB, text/plain)
2016-04-30 13:21 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2016-04-13 04:00:07 UTC
The TB42 build of master (currently the only TB rolling windows builds) are failing on launch with an undetermined error on launch:

Fatal Error

"The application cannot be started.
Extension Manager: exception in synchronize"

Log for the 2016-04-13 build is here...

http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&full-log=1460506809.30745
Comment 1 V Stuart Foote 2016-04-15 00:51:47 UTC
@Christian, *

This evenings 64-bit TB62 build of 5.2.0alpha1+ ID: 21e3cd642b8b478416c498f66ffc4ff22bfa5fc2

is also affected by this. So, not just Thorsten's TB42 32-bit configuration.

Sorry.
Comment 2 V Stuart Foote 2016-04-15 03:43:46 UTC
*** Bug 99309 has been marked as a duplicate of this bug. ***
Comment 3 V Stuart Foote 2016-04-18 23:23:46 UTC
So this exception/crash is still occurring in Windows builds of master:

Looks to be hanging when falling through the try/catch here:

http://opengrok.libreoffice.org/xref/core/desktop/source/deployment/manager/dp_extensionmanager.cxx?#1324

Follow a run in process monitor through to creation of the user profile where it ends with incomplete profile and errors as noted.

Last working Windows TB build we've had was 2016-04-06 with Build ID: 157469896ef56720f33676222b95e81c04ab5c72

@Noel, your https://gerrit.libreoffice.org/#/c/23795/ for work on
"sequence->vector in xmlscript" was the last to touch this, just coincidence it faults here?
Comment 4 Buovjaga 2016-04-21 09:03:48 UTC
No repro.

Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+
Build ID: 3dca8575d63db50b0120fbff09bbfcd056fa3732
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-04-20_05:07:29
Locale: fi-FI (fi_FI)
Comment 5 Dennis Roczek 2016-04-21 09:20:28 UTC
/me has no crash (with opengl disabled) any longer.

The OpenGL problem is something different and tracked in another bug. (the combination of my card + driver)
Comment 6 Christian Lohmaier 2016-04-21 09:30:33 UTC
not sure about "fixed"  - I could not reproduce with the @62 build Stuart mentioned.
If it is openGL related, then its's different story, but neither the old nor the current master builds show the behaviour  - so please Stuart, double-check whether you can still reproduce.
Comment 7 V Stuart Foote 2016-04-21 13:09:26 UTC
Sorry, still have an issue.

Doing /a Administrative installs of the .msi on Windows 10 Pro 64-bit/Windows 8 Ent 64-bit.

While Kendy's TB39 builds have been good from the 19th. I continue getting the error with Christian's TB62 builds. Assume other than 32/64 bitness there is some build difference between Kendy's and Cloph's (or Thorsten's TB42) 

TB39
2016-04-19_09.32.12/    19-Apr-2016 12:28    -   GOOD
2016-04-20_05.07.29/    20-Apr-2016 07:24    -   GOOD
2016-04-21_06.34.25/    21-Apr-2016 08:53    -   GOOD

TB62
2016-04-14_15.37.05/    14-Apr-2016 19:50    -   BAD
2016-04-15_06.48.04/    15-Apr-2016 10:54    -   BAD
2016-04-16_20.39.57/    17-Apr-2016 00:58    -   BAD
2016-04-20_16.47.56/    20-Apr-2016 21:15    -   BAD
Comment 8 m.a.riosv 2016-04-22 10:43:39 UTC
Hi @Stuart,

It's not a dream.:)

I have seen a few days ago, and I can reproduce TB62x86:
Win10x64
master~2016-04-20_19.07.06_LibreOfficeDev_5.2.0.0.alpha0_Win_x86_en-US_de_ar_ja_ru_qtz.msi
(http://dev-builds.libreoffice.org/daily/master/Win-x86@62-merge-TDF/2016-04-20_19.07.06/)

but not with TB39
Version: 5.2.0.0.alpha1+
Build ID: 11f13f55b7e76811946979f363638597d882b88b
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-04-22_01:37:28
Comment 9 m.a.riosv 2016-04-22 21:33:17 UTC
Reproducible with 5.2 pre-release.
Win10x64
http://dev-builds.libreoffice.org/pre-releases/win/x86/
Version: 5.2.0.0.alpha1
Build ID: 902b28a39528b6c92602e9b521a1d0861be1caf9
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default;

Installing with S.I.GUI, in a clean folder.

Copying the registrymodifications.xcu from master TB39, allows to start the program.
Comment 10 Pedro 2016-04-23 08:12:54 UTC
Version Alpha1 does not work under Windows 10 x64

I tested with both x86 and x64, installed in parallel with SI GUI and standard install.
In all situations LO fails with the same error screen posted by Stuart.

It does however run correctly under Win 7 Pro x64 SP1 (at least the x64 version, I didn't test the x86)

Could this be caused my missing MSVC libraries as suggested by Florian in
http://nabble.documentfoundation.org/Libreoffice-qa-ANN-LibreOfficeDev-5-2-0-alpha1-test-builds-available-tp4181683p4181741.html
?
Comment 11 Armin Le Grand 2016-04-25 08:54:03 UTC
Have the same problem with current master:

(a) 32bit win build with debug starts
(b) 64bit win build with debug starts
(c) 32bit win build pro (no debug, just symbols) shows the described problem

-> tried to copy registrymodifications.xcu to instdir/user, still not working
-> copied whole user folder from (a) to (c), LO comes up and runs (!)
=> something in user dir seems to have changed, only triggering in pro builds

my autogen.lastrun from (c):
--with-external-tar=/cygdrive/c/lo/sources/lo-externalsrc
--with-junit=/cygdrive/c/lo/sources/junit-4.10.jar
--with-ant-home=/cygdrive/c/lo/sources/apache-ant-1.9.5
--enable-release-build
--enable-symbols

same from (a):
--with-external-tar=/cygdrive/c/lo/sources/lo-externalsrc
--with-junit=/cygdrive/c/lo/sources/junit-4.10.jar
--with-ant-home=/cygdrive/c/lo/sources/apache-ant-1.9.5
--enable-pch
--disable-ccache
--disable-werror
--enable-dbgutil
--disable-atl
--disable-activex

HTH!
Comment 12 Armin Le Grand 2016-04-25 09:02:58 UTC
registrymodifications.xcu from (c) is just 842 byte. The one from (a) has 423.036 Bytes. Copying it from (a) to (c) works now, but did not initially, seems as if initial-run install stuff hangs. Trying to verify this...
Comment 13 Armin Le Grand 2016-04-25 11:17:57 UTC
Doing the following:
- new creation/build of situation (c) in instdir, the program does not start.
- Change boostrap.ini 'UserInstallation=$SYSUSERCONFIG/LibreOffice/4' -> 'UserInstallation=$ORIGIN/..'
- Next start still does not work, but creates instdir/User dir, containing the too-short registrymodifications.xcu file.
- Replacing this with a registrymodifications.xcu from e.g. a debug-built office
-> next start works

Thus seems to be an error in initially creating registrymodifications.xcu in UserInstallation.
Comment 14 V Stuart Foote 2016-04-25 15:03:43 UTC
On Windows 10 Pro 64-bit en-US

Copied the full User profile (not just the registrymodifications.xcu) from a /a admin install and launch of today's TB39 build (157469896ef56720f33676222b95e81c04ab5c72), to an /a admin install of today's TB42 build (924126df792915092ee6201d1f068e43ffb80b67) and as above the TB42 build launches. Without the copied profile the TB42 builds still crashes during initial launch and profile build.

Also, I was able to do the same for the 520alpha1 x86 build (902b28a39528b6c92602e9b521a1d0861be1caf9) and have it run.  But unable to determine if all the dictionary/thesaurus, NLP solver, and Wiki publisher as bundled are fully configured when opened with a copied user profile from TB39.
Comment 15 Pedro 2016-04-25 15:47:07 UTC
Version Alpha1 creates a limited (In reply to Armin Le Grand (CIB) from comment #13)
> Doing the following:
> - new creation/build of situation (c) in instdir, the program does not start.
> - Change boostrap.ini 'UserInstallation=$SYSUSERCONFIG/LibreOffice/4' ->
> 'UserInstallation=$ORIGIN/..'
> - Next start still does not work, but creates instdir/User dir, containing
> the too-short registrymodifications.xcu file.
> - Replacing this with a registrymodifications.xcu from e.g. a debug-built
> office
> -> next start works
> 
> Thus seems to be an error in initially creating registrymodifications.xcu in
> UserInstallation.

Confirmed. Just overwriting the unexpectedly short registrymodifications.xcu file with a valid one solves the problem.
Comment 16 Armin Le Grand 2016-04-26 09:21:23 UTC
Plus it only happens on product verion, not on debug builds. Who knows about that registrymodifications.xcu and where it gets created at startup?
Comment 17 Christian Lohmaier 2016-04-26 09:46:11 UTC
the registrymodifications.xcu is *meant* to be small, as it only contains stuff that the user configures and hence differs from the defaults.

That file isn't even part of the package, but created by LO when it launches.

Even if that file would be to blame, the problem would be reproducible by not only you three, but by everyone who would try the admin installation method.


Besides that: Why did nobody bother to actually attach working and non-working registrymodifications.xcu?

According to the logic presented here, replacing a working registrymodifications.xcu with the "too short" one would also provoke the crash.

And did anyone try whether that then also causes a regular installation to fail in the same way?

so once again: What is "unexpectedly short"? is it invalid xml because LO was killed while writing it/is it incomplete file? Or just pristine config with no user-overrides?
Comment 18 Pedro 2016-04-26 21:43:53 UTC
Created attachment 124660 [details]
xcu file generated by version 5.2 Alpha1
Comment 19 Pedro 2016-04-26 21:45:55 UTC
Created attachment 124661 [details]
XCU file generated by 5.2 Master daily build from TB#39 (OK)
Comment 20 Pedro 2016-04-26 21:47:34 UTC
(In reply to Christian Lohmaier from comment #17)
> the registrymodifications.xcu is *meant* to be small, as it only contains
> stuff that the user configures and hence differs from the defaults.
> 
> That file isn't even part of the package, but created by LO when it launches.

We are aware of that...

> Even if that file would be to blame, the problem would be reproducible by
> not only you three, but by everyone who would try the admin installation
> method.

You forgot 3 details: 1) The problem "only" affects Win 8+ ; 2) Comment #10 "I tested with both x86 and x64, installed in parallel with SI GUI and standard install." 3) Maybe only the 3 of us bothered to report? Does it require more than 3 people???

> Besides that: Why did nobody bother to actually attach working and
> non-working registrymodifications.xcu?

Good point. Done.

> According to the logic presented here, replacing a working
> registrymodifications.xcu with the "too short" one would also provoke the
> crash.
> And did anyone try whether that then also causes a regular installation to
> fail in the same way?

That doesn't work because there isn't any "good" TDF Master build to test with...
It doesn't crash 5.1.3.1 (x64) though
But it is a different branch so it doesn't prove much...

> so once again: What is "unexpectedly short"? is it invalid xml because LO
> was killed while writing it/is it incomplete file? Or just pristine config
> with no user-overrides?

No, it is not incomplete but an almost empty xml. See attachments.
Comment 21 Christian Lohmaier 2016-04-27 16:03:06 UTC
<item oor:path="/org.openoffice.Office.Common/VCL"><prop oor:name="UseOpenGL" oor:op="fuse"><value>false</value></prop></item>

→ so it *IS* openGL related after all, all points towards this at least.

When using administrative install.Just adding just that to the minimal one and try again.

Neither dev builds nor administrative install touch registry, so the automatic disabling of openGL via registry entry when LO crashes on launch won't trigger/has no effect here.

> You forgot 3 details:

not really..

> 1) The problem "only" affects Win 8+

and has been tested and not reproducied on those machines as well. Indicating even more that this is OpenGL related, (which has been denied previously) -for older versions openGL isn't enabled by default.

> ; 2) Comment #10 "I tested with both x86 and x64, installed in parallel with SI GUI and standard install."

Indeed overlooked the standard install thing.  So even another hint that it has nothing to do with adminstrative install. Just OpenGL not being blacklisted for your driver/graphic card.

> 3) Maybe only the 3 of us bothered to report? Does it require more than 3 people???

That's not the point if X other people try hard to reproduce and cannot.
Comment 22 V Stuart Foote 2016-04-27 17:17:18 UTC
Sorry, but believe  this has nothing to do with OpenGL, both Windows systems (8.1 and 10) this occurs on for me have nVidia drivers that are current and fully supported.

Watching the GUI on launch of a "server" /a admin install, the error messages indicated point to

RID_STR_SYNCHRONIZING_REPOSITORY in dp_manager.src

and

http://opengrok.libreoffice.org/xref/core/desktop/source/deployment/manager/dp_extensionmanager.cxx?#1324

http://opengrok.libreoffice.org/xref/core/desktop/source/deployment/manager/dp_extensionmanager.hxx?a=true#200

IHMO  css::uno::Reference<css::deployment::XPackageManager> getBundledRepository(); during "synchronizing" is suspect here.

And when this aborts (for what ever reason)-- the building of user profile also aborts. Substituting another existing profile may run, but does not seem a desirable workaround.
Comment 23 Christian Lohmaier 2016-04-27 17:53:11 UTC
then your problem might be different from Pedro's and my request to show working and non-working registrymodifications still holds.  If a configuration setting is to blame, then there aren't that many that can have such impact.

And explicit question to you (Stuart) as well: Does it work when doing a full installation, and not a msiexec /a adminsitrative install?
Comment 24 V Stuart Foote 2016-04-27 18:20:34 UTC
(In reply to V Stuart Foote from comment #22)
> Sorry, but believe  this has nothing to do with OpenGL, both Windows systems
> (8.1 and 10) this occurs on for me have nVidia drivers that are current and
> fully supported.

Although, I just did a "server" /a admin install of the 5.2.0alpha1 x86 build on a Windows 7 sp1 64-bit box with an OpenGL blacklisted GPU, and the launch gets past the Synchronize bundled extensions on that system -- and creates a complete user profile and opens completely. 

Still I'm less inclined to believe it is strictly an OpenGL issue, as opposed to an OS issue--so is it somehow in the DirectWrite support?  Does that even get called when "synchronizing" the extensions. 

I have no idea where to look next...
Comment 25 V Stuart Foote 2016-04-27 18:38:30 UTC
(In reply to Christian Lohmaier from comment #23)
> then your problem might be different from Pedro's and my request to show
> working and non-working registrymodifications still holds.  If a
> configuration setting is to blame, then there aren't that many that can have
> such impact.

I think using a profile from another install is just asking for trouble, and the error is reproducible for everyone that has experienced it--same point in the profile creation. It is failing at the try-catch in dp_extensionmanager.cxx at #1358

http://opengrok.libreoffice.org/xref/core/desktop/source/deployment/manager/dp_extensionmanager.cxx?#1358


> 
> And explicit question to you (Stuart) as well: Does it work when doing a
> full installation, and not a msiexec /a adminsitrative install?

You mean adding a WRITEREGISTRY=1 command line flag to the package?  OK, I'll spin up a VM and do it there just for curiosities sake--but understand as I use VMWare Workstation I get a whole different set of Graphics drivers.
Comment 26 V Stuart Foote 2016-04-27 19:47:15 UTC
Same fatal error with a "server" /a administrative install on a clean Windows 8.1 Ent 32-bit VM on VMWare Workstation (12.1.1 build-3770994)

And, with a /i with WRITE_REGISTRY=1, doing a custom (only deselect Quickstart) get this result on first launch:

error on first attempt

LibreOfficeDev 5.2 - Fatal Error
The application cannot be started.
Extension Manager: exception during enableExtension

and on subsequent attempts

LibreOfficeDev 5.2 - Fatal Error
The application cannot be started.
Extension Manager: exception in synchronize

The opengl_device.log for the install read

DriverVersion: 8.15.1.32
DriverDate: 7-15-2015
DeviceID: PCI\VEN_15AD&DEV_0405&SUBSYS_040515AD&REV_00
AdapterVendorID: 0x15ad
AdapterDeviceID: 0x0405
AdapterSubsysID: 0x040515ad
DeviceKey: System\CurrentControlSet\Control\Video\{F28E888F-C896-4494-820F-57C7545587A6}\0000
DeviceString: VMware SVGA 3
Comment 27 Pedro 2016-04-27 20:21:47 UTC
(In reply to Christian Lohmaier from comment #21)
> When using administrative install.Just adding just that to the minimal one
> and try again.

That worked. It is related to the OpenGL detection but something is wrong. See below.

> Neither dev builds nor administrative install touch registry, so the
> automatic disabling of openGL via registry entry when LO crashes on launch
> won't trigger/has no effect here.

Just another reason why BH sessions with Alpha an Beta builds are a waste of time...

> > 1) The problem "only" affects Win 8+
> 
> and has been tested and not reproduced on those machines as well.
> Indicating even more that this is OpenGL related, (which has been denied
> previously) -for older versions openGL isn't enabled by default.

The only failure in your logic is that in this same PC LibreOffice is running correctly with OpenGL enabled since version 5.1.2 (didn't test with previous 5.x builds). In fact it supports OpenGL 4.3 (according to OpenGL Extensions Viewer 4.4.3)

> > ; 2) Comment #10 "I tested with both x86 and x64, installed in parallel with SI GUI and standard install."
> 
> Indeed overlooked the standard install thing.  So even another hint that it
> has nothing to do with adminstrative install. Just OpenGL not being
> blacklisted for your driver/graphic card.
>

Then it is a bug in the OpenGL logic.

> > 3) Maybe only the 3 of us bothered to report? Does it require more than 3 people???
> 
> That's not the point if X other people try hard to reproduce and cannot.

The FACT that it failed in 3 modern PCs where OpenGL should be supported means that there is probably a significative proportion (how many are X?) where OpenGL detection is failing. So dismissing this bug because "it's only the 3 of us" seems absurd.
Comment 28 Luke 2016-04-28 03:01:05 UTC
This is a regression that I can reproduce on my laptop with an Intel HD 5200. Compiling release builds with Visual Studio 2015. So far I have bisected it down to this range. 

https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=+788616fe7ce7c56d9dcfccafdd3e1f55036aa8a7..094faaae6982472375420e57d6b9e34eefdbced8

Adding Tomaž since he made OpenGL commits in that range.
Comment 29 Christian Lohmaier 2016-04-28 14:22:24 UTC
@stuart:

it is about systematically pin down the problem. So just do me the favor and copy just the OpenGL disable config entry into the minimal registrymodifications file you get with administrative install.
Comment 30 V Stuart Foote 2016-04-28 14:57:11 UTC
(In reply to Christian Lohmaier from comment #29)
> @stuart:
> 
> it is about systematically pin down the problem. So just do me the favor and
> copy just the OpenGL disable config entry into the minimal
> registrymodifications file you get with administrative install.

LOL, that just collided with this submission ;-)

(In reply to Christian Lohmaier from comment #21)
> <item oor:path="/org.openoffice.Office.Common/VCL"><prop
> oor:name="UseOpenGL" oor:op="fuse"><value>false</value></prop></item>
> 
> → so it *IS* openGL related after all, all points towards this at least.
> 
> When using administrative install.Just adding just that to the minimal one
> and try again.
> 

As Pedro in comment 27, I added the UseOpenGL false stanza to the minimal registrymodifications.xcu of a failed 520alpah1 launch.  Doing that, on next run 520alpha1 comes up with Default graphics rendering. Closing, the user profile is fully populated--as is the registrymodifications.xcu.

Enabling OpengGL in the GUI, or setting UseOpenGL true in the .xuc, causes LibreOffice to crash. Although I had one hang exactly as in bug 99551 I tried to reproduce to catch a stacktrace but couldn't repeat in a half dozen tries.
Comment 31 Luke 2016-04-28 20:19:26 UTC
Bisect result:

The first bad commit could be any of:
40e9ed91bd8bbfecfc3832d73a81741d0aa97d3a
80d0b2916db81a7f47bb1d368677016bbb870df6

Tomaž,
Could you please take a look at this? These are both your commits.
Comment 32 Tomaz Vajngerl 2016-04-29 14:55:06 UTC
Stack trace would be helpful..
Comment 33 V Stuart Foote 2016-04-29 15:42:55 UTC
(In reply to Tomaz Vajngerl from comment #32)
> Stack trace would be helpful..

Trying, unfortunately can't get a hang to attach WinDbg for a stacktrace.

Out of about 20 cycles through deleting profile, launch, edit profile with UseOpenGL false, 2nd launch set UseOpenGL true, launch--I only had one instance of an actual hang on the splash screen and I didn't think to attach to it with WinDbg.

Meaning, I'll have to try to use sysinternals ProcessMonitor with Symbols and capture it to a PML and search.

If Luke can't post it sooner, I might be able to tease it out of ProcessMonitor over the weekend.
Comment 34 Luke 2016-04-30 02:04:57 UTC
Created attachment 124740 [details]
Screenshot of Fatal Error
Comment 35 Luke 2016-04-30 02:09:52 UTC
Created attachment 124741 [details]
1st attempt to backtrace

WinDbg doesn't seem to recognize the error as an exception. Am I doing something wrong?
Comment 36 Pedro 2016-04-30 03:22:49 UTC
Created attachment 124744 [details]
Backtrace of non-starting LO 5.2 Alpha1 under Windows 10
Comment 37 V Stuart Foote 2016-04-30 04:16:52 UTC
@Luke, if it hangs in WinDbg and !analyze -v is not helpful, you can still get useful stacktrace with a "~* kp" from the WinDbg command line. The first thread should be the main, additional can have some interesting details.

@Tomaž, Pedro's WinDbg !analyze -v posted in comment 36 looks to confirm Luke's bisect result of commit 80d0b2916db81a7f47bb1d368677016bbb870df6

http://opengrok.libreoffice.org/xref/core/vcl/opengl/texture.cxx?a=true#458

and

http://opengrok.libreoffice.org/xref/core/vcl/opengl/gdiimpl.cxx?a=true#1697

@Pedro, can you catch another session in WinDbg--but post up result of the "~* kp" command--which with symbols should expose code lines for more of the stack and specific calls and make it easier to follow what goes wrong.
Comment 38 Tomaz Vajngerl 2016-04-30 06:29:06 UTC
I have make some quick fixes in https://gerrit.libreoffice.org/#/c/24509

Somebody should check if this helps.

I'm going for vacation for a week so I'll continue when I come back...
Comment 39 Buovjaga 2016-04-30 06:45:12 UTC
(In reply to V Stuart Foote from comment #37)
> @Luke, if it hangs in WinDbg and !analyze -v is not helpful, you can still
> get useful stacktrace with a "~* kp" from the WinDbg command line. The first
> thread should be the main, additional can have some interesting details.

Do you mind adding that bit of info to https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg ? :) We could use more advice related to hangs.
Comment 40 Pedro 2016-04-30 08:29:10 UTC
(In reply to V Stuart Foote from comment #37)
> @Pedro, can you catch another session in WinDbg--but post up result of the
> "~* kp" command--which with symbols should expose code lines for more of the
> stack and specific calls and make it easier to follow what goes wrong.

Tomaz already committed a patch so this is no longer necessary

@Christian, would it be possible to have a Win x64 Master daily build from TB62-TDF when the patch is included (in a day or two)?
Comment 41 V Stuart Foote 2016-04-30 13:21:45 UTC
Created attachment 124749 [details]
WinDbg x86 stacktrace with symbols on Windows 10

Was able to attach to the process catch the hang using the "Automation" batch from the Wiki.  Whole stack intact with symbols--yay!, I don't have to try to do it with Process Monitor.  

Confirms Pedro's log, and looks like Tomaž is on top of it (enjoy the vacation).
Comment 42 V Stuart Foote 2016-05-01 21:56:59 UTC
On windows 10 Pro 64-bit en-US with special build

http://dev-builds.libreoffice.org/daily/master/Win-x86@62-merge-TDF/gerrit_24509_2/

Version: 5.2.0.0.alpha1+
Build ID: d8f73e1da3f799b004dec3875f433aa44685fc23
CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-05-01_13:08:56
Locale: en-US (en_US)

Clean initial launch of splash panel and StartCenter opens with OpenGL enabled.
Comment 43 Pedro 2016-05-07 07:50:01 UTC
Tested with

Version: 5.2.0.0.alpha1+
Build ID: 52871b360c73efd59bfbc811b8b89a02b6375b29
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-05-07_01:06:50
Locale: pt-PT (pt_PT)

Still the same problem. 
Program won't start without manually hacking the xcu file.
Comment 44 V Stuart Foote 2016-05-07 08:24:48 UTC
Yes that is correct.

https://gerrit.libreoffice.org/#/c/24509 still needs code review and a final commit. 

Just Christian's TB62 20160501 special testing build as linked from comment 42 contains Tomaz's patch.
Comment 45 Commit Notification 2016-05-08 08:02:18 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d22ca8d8cb050b9006720f39c612c5c32eab8795

tdf#99258 bail out if we fail to reserve the texture

It will be available in 5.2.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 46 Luke 2016-05-10 19:20:20 UTC
(In reply to V Stuart Foote from comment #37)
> @Luke, if it hangs in WinDbg and !analyze -v is not helpful, you can still
> get useful stacktrace with a "~* kp" from the WinDbg command line. 

Could you please elaborate on this on the wiki? 
https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg 

The Windows build is working again for me. Great job everyone!
Comment 47 Commit Notification 2016-05-11 09:55:56 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5d7badd2f2341171733c5fabf111ecf9674bc3d4&h=libreoffice-5-1

tdf#99258 bail out if we fail to reserve the texture + more

It will be available in 5.1.4.

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 48 Pedro 2016-05-23 22:42:38 UTC
Verified fixed under Windows 10 Home x64 with build

Version: 5.2.0.0.alpha1+ (x64)
Build ID: 7bb1a616aa272c96a2662064ed16846f168e6a27
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2016-05-23_12:42:52
Locale: pt-PT (pt_PT)

Thank you!