Description: This does work on: Version: 5.4.3.2 Build ID: 92a7159f7e4af62137622921e809f8546db437e5 CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group and previous versions using a variety of databases (split, PostGreSQL, MySQL, MariaDB). This will not work in: Version: 6.0.0.1 Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group This problem only occurs under specific conditions. Steps to Reproduce: Testing: Using LO v5.4.3.2 (or prior) opening the Base file asks for a PW (click OK - none needed) then opens a form. This is what should happen. Using LO v6.0.0.1 with same Base file just locks up. Notice there isn't even a menu bar displayed. Only way to is to click upper right 'x', wait, then click force quit. Only recovery is to open with v5.4.3.2 or older to recover. Some points worthy of notice. With PW required turned OFF the split file works in v6.0 (haven't tested others as pain setting up various user PW scenarios; also not typical to require no password). Also, with the two lines noted above commented out, all work OK in v6.0 (various DB's) Actual Results: Base file just locks up. Notice there isn't even a menu bar displayed. Only way to is to click upper right 'x', wait, then click force quit. Only recovery is to open with v5.4.3.2 or older to recover. So it appears there is a timing problem with signing in and executing "ThisDataBaseDocument.CurrentController.Connect()". Expected Results: The objective is to open a specific form when starting the Base file. Reproducible: Always User Profile Reset: No Additional Info: The following macro is attached to the "Open Document" of the .odb (in Standard->Module1): SUB OpeningForm Dim ObjTypeWhat Dim ObjName As String Setup ObjName = "MultiForm" ObjTypeWhat = com.sun.star.sdb.application.DatabaseObject.FORM If ThisDatabaseDocument.FormDocuments.hasbyname(ObjName) Then 'Check the form exists' ThisDataBaseDocument.CurrentController.Connect() 'If the form exists connect to the database' ThisDatabaseDocument.CurrentController.loadComponent(ObjTypeWhat, ObjName, FALSE) 'Open the form' Else MsgBox "Error! Wrong form name used. " & ObjName End if End Sub These are the problem lines: ThisDataBaseDocument.CurrentController.Connect() 'If the form exists connect to the database' ThisDatabaseDocument.CurrentController.loadComponent(ObjTypeWhat, ObjName, FALSE) 'Open the form' Attached is a sample (zipped split Base HSQL DB) where "Password Required" is set ON. There is no password involved but this is when the problem happens. By the way, the only way to turn this off now is by editing the 'content.xml' file in the .odb root - See Bug #97416. User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36
Created attachment 138617 [details] Split DB files within .zip file
Same LO-versions here. Could confirm the buggy behavior with OpenSUSE 42.2 64bit rpm Linux.
Created attachment 138632 [details] tail of terminal output from bibisect Working on debian-buster in the recently retired daily Linux dbgutil bibisect repository, I see that the bug came into LibreOffice somewhere in the 39 or so commits to master ... commit date s-h -------- ---------- -------- good 8ba5c4f4 2017-10-13 d029193e bad 9e42902f 2017-10-14 6250b856 I am setting keyword bibisected
Created attachment 138633 [details] gdb output during hang The attached gdb log is from LibreOffice opening the attached .odb. LibreOffice is from a local build of commit 68f7d89c, commited 2017-12-11, configured CC=ccache /usr/bin/gcc CXX=ccache /usr/bin/g++ --enable-option-checking=fatal --enable-dbgutil --enable-debug --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src --without-package-format built and running on debian-buster. The gdb commands are echo info threads thread apply backtrace all info shared I am setting keyword haveBacktrace.
Created attachment 138676 [details] bt with debug symbols On pc Debian x86-64 with master sources updated some days ago, I can't even open the file. I attached bt with symbols.
*** Bug 115548 has been marked as a duplicate of this bug. ***
This must be regression from https://cgit.freedesktop.org/libreoffice/core/commit/?id=d3ae94f04e0cfeba49f5e0de66848743391fc336 > author Jan-Marek Glogowski <glogow@fbihome.de> 2017-10-13 18:55:01 +0200 > committer Jan-Marek Glogowski <glogow@fbihome.de> 2017-10-13 18:55:15 +0200 > commit d3ae94f04e0cfeba49f5e0de66848743391fc336 > tree 9579d3f258edcf5e60d67891912c783fc5b97b0a > parent 3ea6d0620d34c14950c5b1a25af801efd7fde492 > Don't crash on extension update check > We don't need to release the SolarMutex, as we don't own it. The commit removed SolarMutexReleaser from UUIInteractionHelper::handleRequest and UUIInteractionHelper::getStringFromRequest. The hang occurs with deadlock between main thread waiting for solar mutex, and a worker thread (holding the mutex) trying to handle request in main thread. Main thread call stack: > win32u.dll!NtUserMsgWaitForMultipleObjectsEx() > user32.dll!RealMsgWaitForMultipleObjectsEx() > sal3.dll!osl_waitCondition(void * Condition, const TimeValue * pTimeout) Line 82 > vcllo.dll!osl::Condition::wait(const TimeValue * pTimeout) Line 120 > vcllo.dll!SalYieldMutex::doAcquire(unsigned long nLockCount) Line 147 > comphelper.dll!comphelper::SolarMutex::acquire(unsigned long nLockCount) Line 73 > vcllo.dll!WinSalInstance::AcquireYieldMutex(unsigned long nCount) Line 451 > vcllo.dll!Application::AcquireSolarMutex(unsigned long nCount) Line 568 > vcllo.dll!SolarMutexReleaser::~SolarMutexReleaser() Line 1474 > vcllo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 560 > vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents) Line 469 > vcllo.dll!Application::Yield() Line 535 > vcllo.dll!Application::Execute() Line 449 > sofficeapp.dll!desktop::Desktop::Main() Line 1622 > vcllo.dll!ImplSVMain() Line 194 > vcllo.dll!SVMain() Line 233 > sofficeapp.dll!soffice_main() Line 166 > soffice.bin!sal_main() Line 48 > soffice.bin!main(int argc, char * * argv) Line 47 > soffice.bin!WinMain(void * _hinst, void * _dummy, char * _cmdline, int _nshow) Line 47 > soffice.bin!invoke_main() Line 99 > soffice.bin!__scrt_common_main_seh() Line 253 > soffice.bin!__scrt_common_main() Line 296 > soffice.bin!WinMainCRTStartup() Line 17 > kernel32.dll!BaseThreadInitThunk() > ntdll.dll!RtlUserThreadStart() Worker thread call stack: > win32u.dll!NtUserMsgWaitForMultipleObjectsEx() > user32.dll!RealMsgWaitForMultipleObjectsEx() > sal3.dll!osl_waitCondition(void * Condition, const TimeValue * pTimeout) Line 82 > uuilo.dll!osl::Condition::wait(const TimeValue * pTimeout) Line 120 > uuilo.dll!UUIInteractionHelper::handleRequest(const com::sun::star::uno::Reference<com::sun::star::task::XInteractionRequest> & rRequest) Line 176 > uuilo.dll!`anonymous namespace'::UUIInteractionHandler::handle(const com::sun::star::uno::Reference<com::sun::star::task::XInteractionRequest> & rRequest) Line 138 > dbalo.dll!dbaccess::ODatabaseSource::connectWithCompletion(const com::sun::star::uno::Reference<com::sun::star::task::XInteractionHandler> & _rxHandler, bool _bIsolated) Line 1094 > dbalo.dll!dbaccess::ODatabaseSource::connectWithCompletion(const com::sun::star::uno::Reference<com::sun::star::task::XInteractionHandler> & _rxHandler) Line 1032 > dbulo.dll!dbaui::ODatasourceConnector::connect(const com::sun::star::uno::Reference<com::sun::star::sdbc::XDataSource> & _xDataSource, dbtools::SQLExceptionInfo * _pErrorInfo) Line 136 > dbulo.dll!dbaui::ODatasourceConnector::connect(const rtl::OUString & _rDataSourceName, dbtools::SQLExceptionInfo * _pErrorInfo) Line 90 > dbulo.dll!dbaui::OGenericUnoController::connect(const rtl::OUString & _rDataSourceName, const rtl::OUString & _rContextInformation, dbtools::SQLExceptionInfo * _pErrorInfo) Line 929 > dbulo.dll!dbaui::OApplicationController::ensureConnection(dbtools::SQLExceptionInfo * _pErrorInfo) Line 357 > dbulo.dll!dbaui::OApplicationController::connect() Line 326 > mscx_uno.dll!`anonymous namespace'::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy * pThis, bridges::cpp_uno::shared::VtableSlot aVtableSlot, _typelib_TypeDescriptionReference * pReturnTypeRef, long nParams, _typelib_MethodParameter * pParams, void * pUnoReturn, void * * pUnoArgs, _uno_Any * * ppUnoExc) Line 214 > mscx_uno.dll!unoInterfaceProxyDispatch(_uno_Interface * pUnoI, const _typelib_TypeDescription * pMemberTD, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 429 > reflectionlo.dll!stoc_corefl::IdlInterfaceMethodImpl::invoke(const com::sun::star::uno::Any & rObj, com::sun::star::uno::Sequence<com::sun::star::uno::Any> & rArgs) Line 688 > sblo.dll!SbUnoObject::Notify(SfxBroadcaster & rBC, const SfxHint & rHint) Line 2226 > svllo.dll!SfxBroadcaster::Broadcast(const SfxHint & rHint) Line 50 > sblo.dll!SbxVariable::Broadcast(SfxHintId nHintId) Line 182 > sblo.dll!SbxValue::SbxValue(const SbxValue & r) Line 62 > sblo.dll!SbxVariable::SbxVariable(const SbxVariable & r) Line 66 > sblo.dll!SbxMethod::SbxMethod(const SbxMethod & r) Line 867 > sblo.dll!SbiRuntime::FindElement(SbxObject * pObj, unsigned long nOp1, unsigned long nOp2, ErrCode nNotFound, bool bLocal, bool bStatic) Line 3507 > sblo.dll!SbiRuntime::StepELEM(unsigned long nOp1, unsigned long nOp2) Line 3982 > sblo.dll!SbiRuntime::Step() Line 769 > sblo.dll!SbModule::Run(SbMethod * pMeth) Line 1144 > sblo.dll!SbModule::Notify(SfxBroadcaster & rBC, const SfxHint & rHint) Line 810 > svllo.dll!SfxBroadcaster::Broadcast(const SfxHint & rHint) Line 50 > sblo.dll!SbMethod::Broadcast(SfxHintId nHintId) Line 2114 > sblo.dll!SbxValue::Get(SbxValues & rRes) Line 285 > sblo.dll!SbMethod::Call(SbxValue * pRet, SbxVariable * pCaller) Line 2071 > basprovlo.dll!basprov::BasicScriptImpl::invoke(const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & aParams, com::sun::star::uno::Sequence<short> & aOutParamIndex, com::sun::star::uno::Sequence<com::sun::star::uno::Any> & aOutParam) Line 234 > protocolhandlerlo.dll!scripting_protocolhandler::ScriptProtocolHandler::dispatchWithNotification(const com::sun::star::util::URL & aURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lArgs, const com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> & xListener) Line 212 > protocolhandlerlo.dll!scripting_protocolhandler::ScriptProtocolHandler::dispatch(const com::sun::star::util::URL & aURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lArgs) Line 302 > dbalo.dll!dbaccess::`anonymous namespace'::lcl_dispatchScriptURL_throw(const dbaccess::DocumentEventExecutor_Data & _rDocExecData, const rtl::OUString & _rScriptURL, const com::sun::star::document::DocumentEvent & _rTrigger) Line 109 > dbalo.dll!dbaccess::DocumentEventExecutor::documentEventOccured(const com::sun::star::document::DocumentEvent & Event) Line 182 > dbalo.dll!comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::document::XDocumentEventListener,com::sun::star::document::DocumentEvent>::operator()(const com::sun::star::uno::Reference<com::sun::star::document::XDocumentEventListener> & listener) Line 273 > dbalo.dll!comphelper::OInterfaceContainerHelper2::forEach<com::sun::star::document::XDocumentEventListener,comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::document::XDocumentEventListener,com::sun::star::document::DocumentEvent> >(const comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::document::XDocumentEventListener,com::sun::star::document::DocumentEvent> & func) Line 285 > dbalo.dll!comphelper::OInterfaceContainerHelper2::notifyEach<com::sun::star::document::XDocumentEventListener,com::sun::star::document::DocumentEvent>(void(com::sun::star::document::XDocumentEventListener::*)(const com::sun::star::document::DocumentEvent &) NotificationMethod, const com::sun::star::document::DocumentEvent & Event) Line 299 > dbalo.dll!dbaccess::DocumentEventNotifier_Impl::impl_notifyEvent_nothrow(const com::sun::star::document::DocumentEvent & _rEvent) Line 196 > dbalo.dll!dbaccess::DocumentEventNotifier_Impl::processEvent(const comphelper::AnyEvent & _rEvent) Line 230 > comphelper.dll!comphelper::AsyncEventNotifierBase::execute() Line 158 > comphelper.dll!comphelper::AsyncEventNotifierAutoJoin::run() Line 258 > comphelper.dll!threadFunc(void * param) Line 186 > sal3.dll!oslWorkerWrapperFunction(void * pData) Line 58 > ucrtbased.dll!invoke_thread_procedure(unsigned int(*)(void *) procedure, void * const context) Line 92 > ucrtbased.dll!thread_start<unsigned int (__cdecl*)(void * __ptr64)>(void * const parameter) Line 115 > kernel32.dll!BaseThreadInitThunk() > ntdll.dll!RtlUserThreadStart() Adding Jan-Marek: could you please take a look at this?
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0e04523b040785e2ce552143d20adcbb40b61d42 tdf#114676 release the SolarMutex, if we own it 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.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a8a0e22edc53a58b293771ef793e9d6a0ac2f712&h=libreoffice-6-0 tdf#114676 release the SolarMutex, if we own it It will be available in 6.0.2. 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.
Have tested using this version: Version: 6.1.0.0.alpha0+ Build ID: 09fcdbd5e0ae35fb7db8c8784329035edd82573b CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-02-14_23:51:12 Locale: en-US (en_US.UTF-8); Calc: group Confirmed as working.
Works for me on Version: 6.0.2.1 Build ID: 1:6.0.2~rc1-0ubuntu0.17.10.1~lo1 CPU threads: 8; OS: Linux 4.13; UI render: GL; VCL: gtk2; Locale: en-GB (en_GB.UTF-8); Calc: group