Bug 114676 - Base Freezes on DB Connect() macro
Summary: Base Freezes on DB Connect() macro
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.0.0.1 rc
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Jan-Marek Glogowski
URL:
Whiteboard: target:6.1.0 target:6.0.2
Keywords: bibisected, haveBacktrace, regression
: 115548 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-12-24 01:08 UTC by Stang
Modified: 2018-03-02 08:30 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Split DB files within .zip file (2.95 MB, application/zip)
2017-12-24 01:10 UTC, Stang
Details
tail of terminal output from bibisect (2.31 KB, text/plain)
2017-12-24 20:11 UTC, Terrence Enger
Details
gdb output during hang (45.72 KB, text/plain)
2017-12-24 20:15 UTC, Terrence Enger
Details
bt with debug symbols (12.20 KB, text/plain)
2017-12-27 08:53 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stang 2017-12-24 01:08:51 UTC
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
Comment 1 Stang 2017-12-24 01:10:53 UTC
Created attachment 138617 [details]
Split DB files within .zip file
Comment 2 robert 2017-12-24 09:47:41 UTC
Same LO-versions here. Could confirm the buggy behavior with OpenSUSE 42.2 64bit rpm Linux.
Comment 3 Terrence Enger 2017-12-24 20:11:41 UTC
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
Comment 4 Terrence Enger 2017-12-24 20:15:06 UTC
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.
Comment 5 Julien Nabet 2017-12-27 08:53:43 UTC
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.
Comment 6 Stang 2018-02-12 03:59:30 UTC
*** Bug 115548 has been marked as a duplicate of this bug. ***
Comment 7 Mike Kaganski 2018-02-13 09:28:17 UTC
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?
Comment 8 Commit Notification 2018-02-14 16:35:03 UTC
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.
Comment 9 Commit Notification 2018-02-15 12:51:06 UTC
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.
Comment 10 Stang 2018-02-15 14:55:17 UTC
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.
Comment 11 tim 2018-03-02 08:30:18 UTC
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