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
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.
Creating a report also works.
Created attachment 112834 [details] small database with a report defined
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
Created attachment 112835 [details] DB with new report created with LO 4.3.3
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
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).
Sounds like it is Windows specific, and possibly linked to corruption of the XML within the ODB file.
The report named Haeuser from first ODB file opens fine for me in LO master.
As does AnsichtHaeuser from the second ODB file Version: 4.5.0.0.alpha0+ Build ID: c106f83da16726506962e19bcbc3d4c25415b81a Locale: fr_
@Helmut : which version of Java are you using with LO ?
Java version is (Windows) is 1.8.0_31 32-bit
The problems do not yet occur in Windows 7, LO 4.3.3.2, Java 1.8.0_32
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.
German Windows 7 Home Premium 64bit by the way.
Created attachment 112947 [details] Mini dump of freezing application Same on English Windows 8 Professional with JRE 1.8.25. Mini dump is attached.
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
Independently confirmed, setting new, regression
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.
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).
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.
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.
*** Bug 89012 has been marked as a duplicate of this bug. ***
*** Bug 89038 has been marked as a duplicate of this bug. ***
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.
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>
(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
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.
(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.
*** Bug 89162 has been marked as a duplicate of this bug. ***
*** Bug 87522 has been marked as a duplicate of this bug. ***
(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
I can also confirm that it works now.
seems to work ok now.
*** Bug 89197 has been marked as a duplicate of this bug. ***
Confirm it works for me, too.
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
*** Bug 89262 has been marked as a duplicate of this bug. ***
*** Bug 89485 has been marked as a duplicate of this bug. ***
*** Bug 89508 has been marked as a duplicate of this bug. ***
*** Bug 89653 has been marked as a duplicate of this bug. ***