Description: On pc Debian x86-64 with master sources updated today + enable-dbgutil + gtk3, I had a crash when creating a brand new odb file (hsqldb embedded) Steps to Reproduce: 1. Launch Base 2. Let by default option and click Finish button 3. Choose a file name then click save Actual Results: Crash Expected Results: No Crash Reproducible: Always User Profile Reset: Yes Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Created attachment 128458 [details] bt with symbols
Michael: it seems https://cgit.freedesktop.org/libreoffice/core/commit/?id=c00d8271ba443c4f0acf657c226eea4824597f95 revealed some problem. (see bt attached in bugtracker)
It's identical to tdf#103416 but I hadn't retrieved the bt for this one. I'm gonna restart pc because it's after my test with kde4/gen rendering. (see tdf#103666)
I restarted my laptop, same result. BTW, I forgot to put these 2 lines in my log: warn:vcl.gdi:1909:1:vcl/headless/svpgdi.cxx:113: non default depth bitmap, slow convert, upscale the input warn:legacy.osl:1909:1:svtools/source/uno/genericunodialog.cxx:314: OGenericUnoDialog::OnDialogDying: where does this come from? it happens just before the crash.
Created attachment 128460 [details] bt with symbols for OnDialogDying Frame 0 is not exactly the right line since I had to add some lines in it to be sure we stop only when _rEvent.GetWindow() != m_pDialog
Seems to be the same as bug 103515, except the OnDialogDying stuff. Neat BTs.
With master sources updated today, I don't reproduce this. It seems a Heisenbug, should I put WFM and let this one opened so devs bt can take a look to bts?
Hmm - well, if we have a trace - lets just confirm it; the code looked dodgy enough to me =)
About second bt, I tried this: diff --git a/svtools/source/uno/genericunodialog.cxx b/svtools/source/uno/genericunodialog.cxx index 7f1b54b..35e20c7 100644 --- a/svtools/source/uno/genericunodialog.cxx +++ b/svtools/source/uno/genericunodialog.cxx @@ -189,7 +189,7 @@ bool OGenericUnoDialog::impl_ensureDialog_lck() // #i65958# / 2006-07-07 / frank.schoenheit@sun.com pDialog->AddEventListener( LINK( this, OGenericUnoDialog, OnDialogDying ) ); - m_pDialog = pDialog; + m_pDialog.reset(pDialog); return true; } @@ -305,6 +305,7 @@ void SAL_CALL OGenericUnoDialog::initialize( const Sequence< Any >& aArguments ) void OGenericUnoDialog::destroyDialog() { SolarMutexGuard aSolarGuard; + m_pDialog->RemoveEventListener( LINK( this, OGenericUnoDialog, OnDialogDying ) ); m_pDialog.disposeAndClear(); } About the first change, I'm not sure but with second change I don't have "OGenericUnoDialog::OnDialogDying: where does this come from?" with it Any thoughts?
With master sources updated today (8955c3fde60b0621527e4b91576e49778494f926) + make clean && make, I reproduce the crash again! I tested the patch quoted yesterday, no better.
With master sources updated today, I also got a crash when trying to create a brand new Firebird embedded file. I haven't retrieved bt but can see this same logs on console: warn:legacy.osl:2268:1:svtools/source/uno/genericunodialog.cxx:314: OGenericUnoDialog::OnDialogDying: where does this come from? warn:vcl:2268:10:vcl/unx/generic/app/geninst.cxx:128: CheckYieldMutex: 1!=10 soffice.bin: /home/julien/lo/libreoffice/vcl/source/app/dbggui.cxx:47: void ImplDbgTestSolarMutex(): Assertion `ImplGetSVData()->mpDefInst->CheckYieldMutex() && "SolarMutex not locked"' failed. warn:vcl:2268:10:vcl/source/window/dialog.cxx:797: Dialog::StartExecuteModal() - Parent not visible
Testing again with different rendering (gtk, gen) now it works with gtk3 (the one I got by default). I don't know what to think...
With master sources updated today, I could still reproduce this.
*** Bug 104138 has been marked as a duplicate of this bug. ***
Stephan: noticing https://cgit.freedesktop.org/libreoffice/core/commit/?id=e19ffa13594640655841f26d797fcd8f49733932 (and the patch it reverted), thought you might be interested in this one.
I gave a new try with master sources updated today, I still reproduce the problem. I noticed that if I disable autorecovery (Tools/Options/Load-Save/General, uncheck "Save Autorecovery information every") , I could create a new HSQLDB file (and opening Firebird file).
*** This bug has been marked as a duplicate of bug 103515 ***
*** Bug 114401 has been marked as a duplicate of this bug. ***