Bug 113413 - LibO hangs at the JRE Required dialog when creating a New Database
Summary: LibO hangs at the JRE Required dialog when creating a New Database
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.3.1.1 rc
Hardware: All Windows (All)
: high major
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: target:6.1.0 target:6.0.0.1
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Java-Runtime-JRE-Warnings
  Show dependency treegraph
 
Reported: 2017-10-24 19:56 UTC by Telesto
Modified: 2017-12-30 18:45 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot (239.74 KB, image/png)
2017-10-24 19:56 UTC, Telesto
Details
Bibisect log (2.91 KB, text/plain)
2017-10-25 14:45 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-10-24 19:56:02 UTC
Description:
LibO hangs at the JRE Required dialog when creating a New Database

Steps to Reproduce:
1. No JAVA installed
2. Open Base
3. Create a new database (default settings)

Actual Results:  
LibO hangs at a empty JRE required dialog

Expected Results:
A probably error message, without hang


Reproducible: Always

User Profile Reset: No

Additional Info:
Found in
Version: 6.0.0.0.alpha1+
Build ID: b17294826830e278d060c876cf4f94a9b4ec16cc
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-10-23_06:32:42
Locale: nl-NL (nl_NL); Calc: CL


User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Telesto 2017-10-24 19:56:19 UTC
Created attachment 137259 [details]
Screenshot
Comment 2 Xisco Faulí 2017-10-24 20:54:35 UTC
is it reproduced in older version of LibreOffice as well, or just in master ?
Comment 3 Alex Thurgood 2017-10-25 06:50:09 UTC
This sounds like the repaint of the bitmap (for the message) is not being executed, so probably a redraw scheduling issue ? VCL/mutex ?
Comment 4 Telesto 2017-10-25 08:08:44 UTC
no repro with:
Version: 5.2.5.0.0+
Build ID: 78223678b7513ffe46804cb08f2dc5bc899b2bab
CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; 
Locale: nl-NL (nl_NL); Calc: CL

Repro with:
Version: 5.3.1.0.0+
Build ID: aa09fd58bd499a2a2c3a32c5f613892bad54076c
CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; Layout Engine: new; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 5 Telesto 2017-10-25 14:45:59 UTC
Created attachment 137286 [details]
Bibisect log

Bisected to:

author	Michael Stahl <mstahl@redhat.com>	2016-07-27 13:02:52 (GMT)
committer	Michael Stahl <mstahl@redhat.com>	2016-08-03 11:27:44 (GMT)
commit	403eefe81b8a0afe888c60452c17d6b2c5d8343f (patch)
tree	9575751bd99e6992ccbfacd5cb8fd705d3866519
parent	4acac00df5a85ff006ecead06c4018e88caaf401 (diff)
tdf#101136 dbaccess: use SolarMutex in ModelMethodGuard
There is a deadlock here when storing a ODatabaseDocument on a
non-main-thread while the main thread dispatches some event that calls
into ODatabaseDocument, while holding SolarMutex.

The storing of the document also stores BASIC libraries, and since
commit fca62934f492125ea6728fd6d09f0c66c9e4fa69 the SfxLibraryContainer
uses SolarMutex for locking.

Now we could re-investigate that problem, but it seems unrealistic to
expect ODatabaseDocument's implementation will never call anything
that acquires SolarMutex.

Resistance is futile.  Your locking scheme will be assimilated.
Comment 6 Alex Thurgood 2017-10-25 16:28:40 UTC
(In reply to Telesto from comment #5)

Oh look, yet another mutex-in-Base issue ;-) Like playing whackamole...
Comment 7 Alex Thurgood 2017-10-26 08:17:41 UTC
Confirming with LO 5412 on Win10 VM
Comment 8 Alex Thurgood 2017-10-26 08:18:58 UTC
@Michael : any idea ?
Comment 9 Xisco Faulí 2017-10-26 08:23:29 UTC
Adding Cc: to Michael Stahl
Comment 10 Alex Thurgood 2017-10-26 08:27:37 UTC
OK, so watching the process utility in Win10 shows that the processor pegs at 100% and memory usage slowly but steadily increases.

soffice.bin status is given as "not responding".

Thread 2248 appears to be blocking thread 4768.
Comment 11 Alex Thurgood 2017-10-26 08:42:13 UTC
I have a process dump DMP file that I could upload somewhere, but it is 340Mb. Even zipping it won't take it below a size acceptable for BZ.
Comment 12 Michael Stahl (allotropia) 2017-11-24 13:44:16 UTC
i can't reproduce this on Linux, and i can't build on Windows currently;
it's possible that the problem is platfrom specific;
a stack trace of all the "interesting" threads would be helpful
Comment 13 Michael Stahl (allotropia) 2017-12-04 18:34:27 UTC
current master windows build, i don't get a JRE required dialog but a
"The connection to the data source... could not be established"
dialog which doesn't hang.
Comment 14 Telesto 2017-12-04 19:01:04 UTC
Strange. It keeps hanging for me when doing this:
1. Open Base
2. Database Wizard - > Create a new database (HSQLBD)
3. Next
4. Finish
5. Save file

Version: 6.1.0.0.alpha0+
Build ID: cc1db6f2b0ebe05ae807628778835b62df00eca2
CPU threads: 4; OS: Windows 6.3; UI render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-12-02_23:45:34
Locale: nl-NL (nl_NL); Calc: CL

I'm seeing the following warning with running a older debug build (1 Nov)
warn:legacy.osl:3492:3660:svtools/source/uno/genericunodialog.cxx:284: OGenericU                                                            noDialog::OnDialogDying: where does this come from?
Comment 15 Michael Stahl (allotropia) 2017-12-06 08:51:22 UTC
okay, my mistake in trying to reproduce it was that i disabled Java in Tools->Options, but you need it enabled and not have any Java found
on the system.

so i had to disable functions jfw_findAllJREs and jfw_findAndSelectJRE
so we don't find anything.

this should be fixed on master now.
Comment 16 Commit Notification 2017-12-06 08:52:51 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

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

tdf#113413 dbaccess: only use SolarMutex in ODatabaseDocument

It will be available in 6.1.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 17 Commit Notification 2017-12-06 12:02:05 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=83566e416c40c89656714e77d5101a4dbfc2751f&h=libreoffice-6-0

tdf#113413 dbaccess: only use SolarMutex in ODatabaseDocument

It will be available in 6.0.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 18 Rainer Bielefeld Retired 2017-12-30 18:45:20 UTC
No longer reproducible with Version: 6.1.0.0.alpha0+ (x64)
Build ID: c926a1e34672afaa5b7de0e3b08b1537e88fbb6f CPU threads: 4; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-12-24_01:10:03
Locale: de-DE (de_DE); Calc: CL:, my default user profile, Tango theme, only 32Bit JAVA installed.

Following STR from original report A new document will be created. I will get the correct message that JRE is missing (wrong JRE ≙ no JRE), but no longer HANGS.

Was still  REPRODUCIBLE with Version: 5.4.4.2 (x64)
Build-ID: 2524958677847fb3bb44820e40380acbe820f960
CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: group, my default user profile, Tango theme