Invoking the database wizard through a remote UNO connection ends in a crash when the wizard ends (whether through completion or cancellation). See attached script for reproducer (even previously, the UNO call to invoke the wizard never returns until the wizard ends, which is unusual - probably nobody ever noticed this because the occasions when you'd want to invoke the wizard from code are limited)
Created attachment 116121 [details] Reproduction script Reproduction steps: With a master build, - In one terminal: instdir/program/soffice --accept="socket,host=localhost,port=2002;urp;" --invisible - In another terminal: UNO_PATH=$PWD/instdir ./tdf91715.py - Then, when the database wizard appears, either cancel it or finish it
Setting to NEW as a commit (range) has been identified: This began somewhere in the range 9e678c14e4fc8e58b1e0530744f648fa3958d338..d05a64df34fd143670cb939b72abfb32d6b714c7 which is the Timer/Idle work Adding Cc: to tobias.madl.dev@gmail.com; Could you possibly take a look at this one? Thanks
Created attachment 116122 [details] Linux 5.1 master backtrace
Small error in the instructions in comment 1 - to get the correct pyuno installation with system python, the environment variables to set (from within your build directory) to run ./tdf91715.py are: PYTHONPATH=$PWD/instdir/program URE_BOOTSTRAP="vnd.sun.star.pathname:$PWD/instdir/program/fundamentalrc"
Created attachment 116190 [details] console+bt with debug symbols On pc Debian x86-64 with master sources updated today, I could reproduce this. I attached console logs+bt Indeed, I noticed this: warn:vcl:15664:10:vcl/generic/app/geninst.cxx:119: CheckYieldMutex: 1!=10
Noticing VclPtr part, I put this one as blocker for tdf#91310
Hmm; the error here is: #2 0x00007efe51a4cb86 in __assert_fail_base (fmt=0x7efe51b9d830 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7efe4b9f1990 "ImplGetSVData()->mpDefInst->CheckYieldMutex() && \"SolarMutex not locked\"", file=file@entry=0x7efe4b9f1948 That looks like a pretty normal UNO / threading issue that is unrelated to VclPtr; and appears to be related to the new timer/idle work. I guess we are simply not holding the SolarMutex while we're cleaning up all this VCL stuff. Then again - UNO & threading is a horrendous tangled mess from beginning to end. To fix the assert; it would be worth trying the patch below - through 'make check' and also your use-case. diff --git a/svtools/source/uno/genericunodialog.cxx b/svtools/source/uno/genericunodialog.cxx index 4b7f82f..6cabb2b1 100644 --- a/svtools/source/uno/genericunodialog.cxx +++ b/svtools/source/uno/genericunodialog.cxx @@ -313,6 +313,7 @@ void SAL_CALL OGenericUnoDialog::initialize( const Sequence< Any >& aArguments ) void OGenericUnoDialog::destroyDialog() { + SolarMutexGuard aSolarGuard; m_pDialog.disposeAndClear(); } Can you confirm that works ? if so, lets get it in.
Michael: I gave a try to the patch you proposed, it seems it doesn't crash anymore with this! :) However, here's what I get on console after having clicked on Cancel button: warn:legacy.osl:3186:15:svtools/source/uno/genericunodialog.cxx:323: OGenericUnoDialog::OnDialogDying: where does this come from? warn:sal.osl:3186:13:sal/osl/unx/socket.cxx:1800: receive socket [0] failed: EOL warn:binaryurp:3186:13:binaryurp/source/reader.cxx:123: caught UNO exception 'acc_socket.cxx:SocketConnection::read: error - Success' warn:binaryurp:3186:13:binaryurp/source/bridge.cxx:846: undisposed bridge, potential deadlock ahead But perhaps it's normal (after all, they're just warnings).
Michael - any thoughts of my banal but potentially correct patch to GenericUnoDialog ? =)
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0a7375e372ee9583d31d44a7cc7b6a21e6197bf1 tdf#91715: lock SolarMutex from dbaui::~ODatabaseAdministrationDialog() It will be available in 5.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.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0fb49c071f8f6b1569a8cf20f7fc598b098b1eb5&h=libreoffice-5-0 tdf#91715: lock SolarMutex from dbaui::~ODatabaseAdministrationDialog() It will be available in 5.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.
Considering Michael's patches, let's consider this one as FIXED.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]