@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.

*** Bug 99309 has been marked as a duplicate of this bug. ***

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?

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)

/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)

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.

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

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

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.

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
?

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!

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...

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.

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.

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.

Plus it only happens on product verion, not on debug builds. Who knows about that registrymodifications.xcu and where it gets created at startup?

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?

Created attachment 124660 [details]
xcu file generated by version 5.2 Alpha1

Created attachment 124661 [details]
XCU file generated by 5.2 Master daily build from TB#39 (OK)

(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.

<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.

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.

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?

(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...

(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.

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

(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.

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.

@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.

(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.

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.

Stack trace would be helpful..

(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.

Created attachment 124740 [details]
Screenshot of Fatal Error

Created attachment 124741 [details]
1st attempt to backtrace

WinDbg doesn't seem to recognize the error as an exception. Am I doing something wrong?

Created attachment 124744 [details]
Backtrace of non-starting LO 5.2 Alpha1 under Windows 10

@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.

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...

(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.

(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)?

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).

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.

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.

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.

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.

(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!

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.

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!