How to reproduce : 1) Load ODT file from bug 88814 2) Right mouse button click on a header in the first grid control on the form. 3) Error message : file:///home/hanspeter/Documents/In%20Bearbeitung/TestAdressen.odb 4) LO promptly crashes. It seems that LO is unable to recover from a missing URL object, i.e. the object pointed to by the form control. Will try and attach bt.
Terminal output at moment of crash : warn:legacy.osl:79719:1:forms/source/component/DatabaseForm.cxx:2843: caught an exception! in function:bool frm::ODatabaseForm::implEnsureConnection() type: com.sun.star.lang.WrappedTargetException message: file:///home/hanspeter/Documents/In%20Bearbeitung/TestAdressen.odb context: N8dbaccess16ODatabaseContextE warn:vcl.control:79719:1:vcl/source/control/button.cxx:2236: No new-style group set on radiobutton <> using old-style digging around Process 79719 exited with status = 77 (0x0000004d)
Test version of LO : Version: 4.5.0.0.alpha0+ Build ID: c106f83da16726506962e19bcbc3d4c25415b81a Locale: fr_ I'm unable to get a trace on this as trying to obtain a bt after the crash lldb tells me there are no threads left running. I would put a break on the message box (or activation of the OK button ?) button, but have no idea which function is responsible for that.
On pc Debian x86-64 with master sources updated today, I could reproduce this. Here are console logs: warn:legacy.osl:4348:1:forms/source/component/DatabaseForm.cxx:2843: caught an exception! in function:bool frm::ODatabaseForm::implEnsureConnection() type: com.sun.star.lang.WrappedTargetException message: file:///home/hanspeter/Documents/In%20Bearbeitung/TestAdressen.odb context: N8dbaccess16ODatabaseContextE
Created attachment 112840 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I could retrieve a bt by putting "catch throw" and gdb + some patience
I noticed in bt the call of this function "dbtools::getConnection_allowException" but no method should take care of the exception, which one should do it? Or should we call "getConnection_withFeedback"? (see http://opengrok.libreoffice.org/xref/core/connectivity/source/commontools/dbtools.cxx#311)
Just reading a bit in these methods, I noticed this: 340 // helper function which allows to implement both the connectRowset and the ensureRowSetConnection semantics 341 // if connectRowset (which is deprecated) is removed, this function and one of its parameters are 342 // not needed anymore, the whole implementation can be moved into ensureRowSetConnection then) See http://opengrok.libreoffice.org/xref/core/connectivity/source/commontools/dbtools.cxx#340 git log --follow -S 'if connectRowset (which is deprecated)' connectivity/source/commontools/dbtools.cxx gives this: commit 1c86cafd95c64e085f912fffbeb30c4f4937626b Author: Jens-Heiner Rechtien <hr@openoffice.org> Date: Fri Sep 23 10:36:41 2005 +0000 (!!!)
With the gdb commands catch throw and catch catch You can put breakpoints on an exception being thrown (then go up in the stack) and caught, respectively, and see what exception is thrown from where. Compare with the case of e.g. a wrong password or hostname when connecting to a database. This is handled correctly. How is that handled? What exception is thrown where and caught where? The exception that causes this crash (which is probably more accurately an abort() due to an uncaught exception) should probably be caught at the same place. If the exception that causes this abort is of a fundamentally different type than the case of wrong password / hostname. For example, assume the former is "IO error" exception, and the latter is "SQLException), then you need to catch the "IO error" exception at a suitable place (within the driver) and rethrown a SQLException out of it.
Quite impressive the number of exceptions retrieved by "catch catch" just to start LO, as if some people have thought that using exception to deal normal cases was ok. If I'm wrong and if all these exceptions correspond to bugs, we really have a problem here. The most annoying during this gdb session is as soon as you hover the grid, gdb goes in a catch so couldn't get nothing more interesting here :-(
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=863122b9adecedfcf35ffac1354ef8a85d5b6827 Resolves: tdf#88825 absent datasource causes exception / abort It will be available in 4.5.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=eaf6618df939ac5c41281ddf6744c4e8a0f687c5&h=libreoffice-4-3 Resolves: tdf#88825 absent datasource causes exception / abort It will be available in 4.3.7. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=58d26c75fc30f1fff45b7e3b5cb9b52521ffa810&h=libreoffice-4-4 Resolves: tdf#88825 absent datasource causes exception / abort 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.