Download it now!
Bug 88824 - Open/Create a report in Base causes LO to freeze (Windows)
Summary: Open/Create a report in Base causes LO to freeze (Windows)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: Other Windows (All)
: high critical
Assignee: Stephan Bergmann
URL:
Whiteboard: target:4.4.1
Keywords: haveBacktrace, regression
: 87522 89012 89038 89162 89197 89262 89485 89508 89653 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-01-27 14:15 UTC by Helmut Leininger
Modified: 2015-02-25 15:48 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
small database with a report defined (49.52 KB, application/vnd.oasis.opendocument.database)
2015-01-27 18:15 UTC, Helmut Leininger
Details
DB with new report created with LO 4.3.3 (58.69 KB, application/vnd.oasis.opendocument.database)
2015-01-27 18:39 UTC, Helmut Leininger
Details
Mini dump of freezing application (4.68 MB, application/octet-stream)
2015-01-30 10:38 UTC, Gerhard Schaber
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Helmut Leininger 2015-01-27 14:15:37 UTC
When trying to create a new report in LO Base, Lo freezes. The same happens when trying to open/run an already existing report. This makes the reporting in Base completetely unuseable
Comment 1 Alex Thurgood 2015-01-27 17:46:34 UTC
Works for me on


Version: 4.4.0.3
Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Locale: fr_

OSX 10.10.1

I can connect to remote mysql instance and open a previously created report no problem.

What datasource are you using as your database backend ?
Embedded hsqldb ?
Embedded Firebird ?

Some other db engine ?


Please also provide a test ODB file containing a report so that we can test.
This might be a windows only problem.

Setting to NEEDINFO pending requested information.
Comment 2 Alex Thurgood 2015-01-27 17:51:24 UTC
Creating a report also works.
Comment 3 Helmut Leininger 2015-01-27 18:15:39 UTC
Created attachment 112834 [details]
small database with a report defined
Comment 4 Helmut Leininger 2015-01-27 18:16:52 UTC
It happens with every type of DB. E.g. 
- embedded HSQL, created from scratch, one table created by the wizard. Trying to create a report (in design mode or by the wizard) freezes LO.
- ODBc - SQLite: when trying to create a report as above.
- embedded HSQL with an existing report: trying to open or modify the report freezes LO
Comment 5 Helmut Leininger 2015-01-27 18:39:11 UTC
Created attachment 112835 [details]
DB with new report created with LO 4.3.3
Comment 6 Helmut Leininger 2015-01-27 18:40:30 UTC
I added a report to the database of the last previuos attachment, using LO 4.3.3 in Ubuntu and renamed the databse.
Now, the new report can be opened using LO 4.4.0.3 in Windows 8.1. I ttach the modified database.
New reports cannot be created in Windows / LO 4.4.0.3
Comment 7 Helmut Leininger 2015-01-27 19:58:07 UTC
Downloaded 4.4.0.3-3 and installed on Ubuntu and made another test with Hausadressen1.odb (second attachment)

Summary of testing results:
Ubuntu an LO 4.4.0.3-3: everything seems to work.

Windows 8.1, LO 4.4.0.2:
New reports cannot be created (freeze).
Report Ansicht_Häuser_Adressen (added in Ubuntu with LO 4.3.3) can be executed and modified.
Report Haeuser (created with older version of LO in Windows) can neither be executed nor opend for modification (freeze).
Comment 8 Alex Thurgood 2015-01-28 17:53:59 UTC
Sounds like it is Windows specific, and possibly linked to corruption of the XML within the ODB file.
Comment 9 Alex Thurgood 2015-01-28 17:56:41 UTC
The report named Haeuser from first ODB file opens fine for me in LO master.
Comment 10 Alex Thurgood 2015-01-28 17:58:43 UTC
As does AnsichtHaeuser from the second ODB file

Version: 4.5.0.0.alpha0+
Build ID: c106f83da16726506962e19bcbc3d4c25415b81a
Locale: fr_
Comment 11 Alex Thurgood 2015-01-28 17:59:56 UTC
@Helmut : which version of Java are you using with LO ?
Comment 12 Helmut Leininger 2015-01-28 18:22:34 UTC
Java version is (Windows) is 1.8.0_31 32-bit
Comment 13 Helmut Leininger 2015-01-29 13:26:38 UTC
The problems do not yet occur in Windows 7, LO 4.3.3.2, Java 1.8.0_32
Comment 14 Gerhard Schaber 2015-01-29 20:20:58 UTC
Same here. LO 4.4.0 freezes, if I try to open the report designer with a completely new database. Of course it happens with existing ones as well.
I tried with JRE 1.8.25 and 1.8.31 and LO 4.4.0 beta2 and 4.4.0.3.

No problems with starting the report designer with LO 4.3.5.2.
Comment 15 Gerhard Schaber 2015-01-29 20:32:20 UTC
German Windows 7 Home Premium 64bit by the way.
Comment 16 Gerhard Schaber 2015-01-30 10:38:01 UTC
Created attachment 112947 [details]
Mini dump of freezing application

Same on English Windows 8 Professional with JRE 1.8.25. Mini dump is attached.
Comment 17 Gerhard Schaber 2015-01-30 10:41:02 UTC
It does not seem to get out of sal3.dll!osl_joinWithThread:

wow64cpu.dll!TurboDispatchJumpAddressEnd+0x536
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x3a5
wow64.dll!Wow64SystemServiceEx+0x26a
wow64.dll!Wow64LdrpInitialize+0x435
ntdll.dll!LdrGetKnownDllSectionHandle+0x1b5
ntdll.dll!WinSqmCheckEscalationSetDWORD+0x11739
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForSingleObject+0xc
KERNELBASE.dll!WaitForSingleObject+0x12
sal3.dll!osl_joinWithThread+0x19
rptlo.dll!?isSetModifiedEnabled@OReportDefinition@reportdesign@@EAAEXZ+0x9f
rptlo.dll!?disposing@OReportDefinition@reportdesign@@MAAXXZ+0x490
cppuhelper3MSC.dll!?dispose@WeakComponentImplHelperBase@cppu@@UAAXXZ+0xbd
rptlo.dll!?dispose@OReportDefinition@reportdesign@@EAAXXZ+0x1a
cppuhelper3MSC.dll!?createFactoryProxy@cppu@@YA?AV?$Reference@VXSingleServiceFactory@lang@star@sun@com@@@uno@star@sun@com@@ABV?$Reference@VXMultiServiceFactory@lang@star@sun@com@@@3456@ABV23456@@Z+0xc55
cppuhelper3MSC.dll!?createFactoryProxy@cppu@@YA?AV?$Reference@VXSingleServiceFactory@lang@star@sun@com@@@uno@star@sun@com@@ABV?$Reference@VXMultiServiceFactory@lang@star@sun@com@@@3456@ABV23456@@Z+0xa13
cppuhelper3MSC.dll!?acquire@?$WeakImplHelper1@VXSingleComponentFactory@lang@star@sun@com@@@cppu@@UAAXXZ+0x3c48
cppuhelper3MSC.dll!?acquire@?$WeakImplHelper1@VXSingleComponentFactory@lang@star@sun@com@@@cppu@@UAAXXZ+0x3ef8
embobj.dll!?release@?$WeakImplHelper1@VXCloseListener@util@star@sun@com@@@cppu@@UAAXXZ+0x33d8
embobj.dll!?release@?$WeakImplHelper1@VXCloseListener@util@star@sun@com@@@cppu@@UAAXXZ+0x457c
embobj.dll!?release@?$WeakImplHelper1@VXCloseListener@util@star@sun@com@@@cppu@@UAAXXZ+0xc132
embobj.dll!embobj_component_getFactory+0x4891
dbalo.dll!?getTypes@?$WeakImplHelper1@VXInteractionDocumentSave@sdb@star@sun@com@@@cppu@@UAA?AV?$Sequence@VType@uno@star@sun@com@@@uno@star@sun@com@@XZ+0x2a14
dbalo.dll!?getTypes@?$WeakImplHelper1@VXInteractionDocumentSave@sdb@star@sun@com@@@cppu@@UAA?AV?$Sequence@VType@uno@star@sun@com@@@uno@star@sun@com@@XZ+0x130e
dbalo.dll!?setUserName@OAuthenticationContinuation@dbaccess@@UAAXABVOUString@rtl@@@Z+0xaa21
dbulo.dll!?suspend@DBSubComponentController@dbaui@@UAAEE@Z+0x17087
dbulo.dll!?initialize@ODataView@dbaui@@UAEXXZ+0x1105
dbulo.dll!??4IController@dbaui@@QAEAAV01@ABV01@@Z+0x4317
dbulo.dll!?executeChecked@OGenericUnoController@dbaui@@UAEXABUURL@util@star@sun@com@@ABV?$Sequence@UPropertyValue@beans@star@sun@com@@@uno@567@@Z+0xcb
dbulo.dll!??0Point@@QAE@JJ@Z+0xbeb0
dbulo.dll!??0Point@@QAE@JJ@Z+0x9a95
vcllo.dll!?ImplAsyncFocusHdl@Window@vcl@@QAEJPAX@Z+0x2445
vcllo.dll!?ImplAsyncFocusHdl@Window@vcl@@QAEJPAX@Z+0x2f06
vcllo.dll!?ImplAsyncFocusHdl@Window@vcl@@QAEJPAX@Z+0x39fd
vcllo.dll!?OpenTTFontBuffer@vcl@@YAHPBXKKPAPAU_TrueTypeFont@1@@Z+0x46d88
vcllo.dll!?OpenTTFontBuffer@vcl@@YAHPBXKKPAPAU_TrueTypeFont@1@@Z+0x4a365
vcllo.dll!?OpenTTFontBuffer@vcl@@YAHPBXKKPAPAU_TrueTypeFont@1@@Z+0x4a920
USER32.dll!CallNextHookEx+0x1c5
USER32.dll!WaitMessage+0x11b
USER32.dll!RegisterWindowMessageW+0xa6c
USER32.dll!DispatchMessageW+0x10
vcllo.dll!?OpenTTFontBuffer@vcl@@YAHPBXKKPAPAU_TrueTypeFont@1@@Z+0x17227
vcllo.dll!?OpenTTFontBuffer@vcl@@YAHPBXKKPAPAU_TrueTypeFont@1@@Z+0x17a43
vcllo.dll!?Execute@Application@@SAXXZ+0x69
vcllo.dll!?DeInitVCL@@YAXXZ+0x634
soffice.bin+0x101e
soffice.bin!main+0x27f
icudt53.dll!icudt53_dat+0x11e2a43
icudt53.dll!icudt53_dat+0xeb2638
Comment 18 Alex Thurgood 2015-01-30 13:22:47 UTC
Independently confirmed, setting new, regression
Comment 19 Julien Nabet 2015-01-30 18:18:45 UTC
I noticed that Win and Unx implement quite differently function "osl_joinWithThread" seen in bt (https://bugs.documentfoundation.org/show_bug.cgi?id=88824#c17), see:
http://opengrok.libreoffice.org/xref/core/sal/osl/unx/thread.cxx#428
http://opengrok.libreoffice.org/xref/core/sal/osl/w32/thread.c#312
for example no mutex in Win (but perhaps it's ok?)
That could explain the fact that it can only be reproduced in Windows.
Comment 20 Lionel Elie Mamane 2015-01-30 19:55:33 UTC
Stephan? Since you:

 * touched code near the top of the backtrace
 * in a way that involves adding joining threads
 * in the right timeframe for the timeframe of the regression
   (that is, on libreoffice-4-4 but not on libreoffice-4-3
 * the freeze seems to be in joining a thread

I'm dumping that on you.

Could you please take a look at this? Thanks.

Bug 87522 and bug 87241 and bug 88824 may be related.

Schaber, Alex, at what moment in creation does that happen? Clicking "finish" in the wizard? Or just before/after the wizard dialog appears? Some time inbetween?

(In reply to schaber from comment #17)
> It does not seem to get out of sal3.dll!osl_joinWithThread:

This means that it is waiting or another thread... What do the other threads look like? (The "mini dump of freezing application" file seems to be some binary format that needs some specialised, probably Windows-only, tool to read...)

> sal3.dll!osl_joinWithThread+0x19
> rptlo.dll!?isSetModifiedEnabled@OReportDefinition@reportdesign@@EAAEXZ+0x9f
> rptlo.dll!?disposing@OReportDefinition@reportdesign@@MAAXXZ+0x490

Is that a backtrace? I don't understand how it gets from reportdesign::OReportDefinition::isSetModifiedEnabled to osl_joinWithThread, nor how it gest from reportdesign::OReportDefinition::disposing to reportdesign::OReportDefinition::isSetModifiedEnabled

Anyway, if mutexes are not reentrant on Windows, then that might be the problem, since both these functions take m_aMutex. But I doubt mutexes are not reentrant, we would have FAR more problems than that.

If I ignore the reportdesign::OReportDefinition::isSetModifiedEnabled there, then things actually make more sense, since the freeze seems to be in osl_joinThread and reportdesign::OReportDefinition::disposing calls that (via the C++ wrapper class Thread method join, which calls osl_joinThread).
Comment 21 Gerhard Schaber 2015-01-30 20:38:43 UTC
There is no dialog. No matter if I use the wizard or directly try to open the design mode, LO immediately freezes. No dialog, no Java console (I enabled the Java console in the Windows settings), nothing. It just freezes.

The bt I took via Process Explorer.
Comment 22 Gerhard Schaber 2015-02-02 11:14:24 UTC
It could be a coincidence, but my feeling is that with LibreOffice 4.4 my desktop often kind of freezes. I cannot close other application windows. It seems like LO captures the mouse in certain situations. Only killing LibreOffice restores the responsiveness of the desktop. Sometimes switching between the tasks helps. I was not able to narrow this down further. In any case, killing LO always helps whereas killing any of the other open applications does not. I am not sure whether this is related or not. With LO 4.3.5.2 I did not have this problem, neither with OpenOffice 4.1.1.
Comment 23 Alex Thurgood 2015-02-02 13:44:04 UTC
*** Bug 89012 has been marked as a duplicate of this bug. ***
Comment 24 Alex Thurgood 2015-02-02 13:46:05 UTC
*** Bug 89038 has been marked as a duplicate of this bug. ***
Comment 25 Stephan Bergmann 2015-02-03 09:05:18 UTC
The problem is as follows:

* On Windows, any FactoryLoader threads spawned from the first OReportDefinition ctor -> OReportDefinition::init (reportdesign/source/core/api/ReportDefinition.cxx) end up calling WinSalInstance::CreateFrame blocking on a call to SendMessageW (which blocks until the message has been processed, by the main thread's event loop).

* On the main thread, CreateDocument (embeddedobj/source/commonembedding/persistence.cxx) is trying createInstanceWithArgumentsAndContext, and if that throws an exception (because the requested service does not support XInitialization) calls just createInstanceWithContext.

* OReportDefinition does not support XInitialization, and thus OSingleFactoryHelper::createInstanceWithArgumentsAndContext (cppuhelper/source/factory.cxx), before throwing the exception, disposes the OReportDefinition instance.

* OReportDefinition::dispose (on the main thread) tries to join any FactoryLoader threads (blocked waiting on the main thread's event loop).

The immediate hotfix thus appears to be to make OReportDefinition trivially support XInitialization (by just ignoring any call to initialize).

However, that would not really help, as shortly after that first OReportDefinition instance gets synchronously disposed on the main thread when dbaui::OApplicationController::openElementWithArguments's case E_FORM (dbaccess/source/ui/app/AppController.cxx) is done with its xDefinition (referencing a dbaccess::ODocumentDefinition ultimately holding the OReportDefinition), so would still block.

The best fix would therefore be to get rid of the FactoryLoader threads.  It is unclear what they are supposed to be good for.  They got introduced with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=bda7e683aeb1e4f64967a0cb2bd69c9152c44037> "CWS-TOOLING: integrate CWS dba32b" which is the cumulation of more than 300 individual commits, without any hint of a rationale.

As FactoryLoader::execute effectively just calls loadComponentFromURL with "Hidden" set to true, immediately followed by a dispose of the obtained component, and does not synchronize with any other thread for communication, it looks like it is either unnecessary, or an alleged performance optimization (e.g., causing things to be preloaded), or a race condition.

Assuming it is an alleged performance optimization, the solution is thus to just remove the FactoryLoader threads.  Not being able to reliably join a spawned thread (so it can wreak havoc during exit) is deemed worse than a potential performance degradation.
Comment 26 Stephan Bergmann 2015-02-03 09:20:51 UTC
fixed on master towards LO 4.5 now with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=75509c995bd51275d39cfd8fd2bd747b0f619b1c> "tdf#88824: Remove FactoryLoader threads causing deadlock on Windows;" requested backport to libreoffice-4-4 towards LO 4.4.1 at <https://gerrit.libreoffice.org/14294>
Comment 27 Stephan Bergmann 2015-02-03 09:29:27 UTC
(In reply to Stephan Bergmann from comment #25)
> As FactoryLoader::execute effectively just calls loadComponentFromURL with
> "Hidden" set to true, immediately followed by a dispose of the obtained
> component, and does not synchronize with any other thread for communication,
> it looks like it is either unnecessary, or an alleged performance
> optimization (e.g., causing things to be preloaded), or a race condition.
> 
> Assuming it is an alleged performance optimization, the solution is thus to
> just remove the FactoryLoader threads.  Not being able to reliably join a
> spawned thread (so it can wreak havoc during exit) is deemed worse than a
> potential performance degradation.

@Lionel: or do you have further insight what the FactoryLoader threads would be needed for?

@QA: would be great to test this fix thoroughly for regressions in the area of database reports, esp. if it hits LO 4.4.1
Comment 28 Commit Notification 2015-02-03 15:41:35 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d8b5dbb2212b85abe60d4a477c3f65e87e74797&h=libreoffice-4-4

tdf#88824: Remove FactoryLoader threads causing deadlock on Windows

It will be available in 4.4.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 29 Lionel Elie Mamane 2015-02-03 15:43:55 UTC
(In reply to Stephan Bergmann from comment #27)
> @Lionel: or do you have further insight what the FactoryLoader threads would
> be needed for?

No, I don't.
Comment 30 Alex Thurgood 2015-02-06 10:12:00 UTC
*** Bug 89162 has been marked as a duplicate of this bug. ***
Comment 31 Lionel Elie Mamane 2015-02-06 10:54:12 UTC
*** Bug 87522 has been marked as a duplicate of this bug. ***
Comment 32 ribotb 2015-02-06 15:03:35 UTC
(In reply to Commit Notification from comment #28)
> 
> Affected users are encouraged to test the fix and report feedback.

Tested with Version: 4.4.1.0.0+
Build ID: e9bac857d7e3e783878422618ac03ff42d68fc27
TinderBox: Win-x86@51-TDF, Branch:libreoffice-4-4, Time: 2015-02-06_06:47:41
Locale: fr_FR
under Windows 7 / x86.

It's ok for me : I can create/edit/open reports.
Tested with embedded HSQLDB database and connected (MySQL ODBC) database.

Bernard
Comment 33 Gerhard Schaber 2015-02-06 15:30:26 UTC
I can also confirm that it works now.
Comment 34 Helmut Leininger 2015-02-06 15:40:27 UTC
seems to work ok now.
Comment 35 raal 2015-02-07 15:55:50 UTC
*** Bug 89197 has been marked as a duplicate of this bug. ***
Comment 36 WKarl 2015-02-09 07:41:52 UTC
Confirm it works for me, too.
Comment 37 christian.carrouge 2015-02-09 10:53:04 UTC
It is ok with version 4.4.1.0.0+ under Windows 7/64.
Thank you to the developers

I expect now version 4.4.1 RC soon. Thank you
Comment 38 raal 2015-02-10 08:09:53 UTC
*** Bug 89262 has been marked as a duplicate of this bug. ***
Comment 39 raal 2015-02-20 07:33:53 UTC
*** Bug 89485 has been marked as a duplicate of this bug. ***
Comment 40 raal 2015-02-20 20:29:18 UTC
*** Bug 89508 has been marked as a duplicate of this bug. ***
Comment 41 Alex Thurgood 2015-02-25 15:48:58 UTC
*** Bug 89653 has been marked as a duplicate of this bug. ***