Created attachment 84783 [details] Apple crash backtrace When attempting to create a new ODB with embedded hsqldb as the db engine, via the database creation wizard LO crashes consistently on the last step of the wizard, where the database gets registered. The ODB file is created and can subsequently be opened after a restart of LO, but any attempt to click on the "Tables"button causes LO to crash again. Apple Backtrace included. As this is a non-debug build, I have no symbols. Alex
Tested on master build 64bit : Version: 4.2.0.0.alpha0+ Build ID: 2395ae8d2ecb5b527d8856ddbce4831a6d2a7092
More tests revealed that : - changing the JDK makes no difference, tested both Apple 1.6 and Oracle Java 1.7; - the same problem occurs with embedded Firebird db. Alex
warning: Tried to remove a non-existent library: /Applications/LibreOfficeDev.app/Contents/MacOS/libfirebird_sdbclo.dylib libc++abi.dylib: terminate called throwing an exception Program received signal SIGABRT, Aborted. 0x00007fff8b39f212 in __pthread_kill () (gdb) bt full thread apply No symbol table is loaded. Use the "file" command. (gdb) bt #0 0x00007fff8b39f212 in __pthread_kill () #1 0x00007fff8f56eb54 in pthread_kill () #2 0x00007fff8f5b2dce in abort () #3 0x00007fff9745d9eb in abort_message () #4 0x00007fff9745b39a in default_terminate () #5 0x00007fff8b64e887 in _objc_terminate () #6 0x00007fff9745b3c9 in safe_handler_caller () #7 0x00007fff9745b3b8 in unexpected_defaults_to_terminate () #8 0x00007fff9745b408 in __cxxabiv1::__unexpected () #9 0x00007fff9745c331 in __cxa_call_unexpected () #10 0x0000000111cbb2df in drivermanager::OSDBCDriverManager::getDriverByURL () #11 0x0000000111cbb302 in non-virtual thunk to drivermanager::OSDBCDriverManager::getDriverByURL(rtl::OUString const&) () #12 0x0000000111c7776b in connectivity::OPoolCollection::isPoolingEnabledByUrl () #13 0x0000000111c7821e in connectivity::OPoolCollection::getDriverByURL () #14 0x0000000111c78562 in non-virtual thunk to connectivity::OPoolCollection::getDriverByURL(rtl::OUString const&) () #15 0x000000010e3d6037 in dbaccess::ODatabaseSource::buildLowLevelConnection () #16 0x000000010e3d40e0 in dbaccess::ODatabaseSource::buildIsolatedConnection () #17 0x000000010e3d3ba5 in dbaccess::OSharedConnectionManager::getConnection () #18 0x000000010e3da809 in dbaccess::ODatabaseSource::getConnection () #19 0x000000010e3dab85 in non-virtual thunk to dbaccess::ODatabaseSource::getConnection(rtl::OUString const&, rtl::OUString const&) () #20 0x0000000110092497 in dbaui::ODatasourceConnector::connect () #21 0x0000000110092148 in dbaui::ODatasourceConnector::connect () #22 0x000000010ffd1349 in dbaui::OGenericUnoController::connect () #23 0x000000010ff6c096 in dbaui::OApplicationController::ensureConnection () #24 0x000000010ff56ed5 in dbaui::OApplicationController::onContainerSelect () #25 0x000000010ff579c0 in non-virtual thunk to dbaui::OApplicationController::onContainerSelect(dbaui::ElementType) () #26 0x000000010ff84a84 in dbaui::OApplicationSwapWindow::OnContainerSelectHdl () #27 0x000000010ff845f9 in dbaui::OApplicationSwapWindow::LinkStubOnContainerSelectHdl () #28 0x0000000100f26301 in SvtIconChoiceCtrl::ClickIcon () #29 0x0000000100f1a2d3 in SvxIconChoiceCtrl_Impl::SelectEntry () #30 0x0000000100f1a748 in SvxIconChoiceCtrl_Impl::SetCursor () #31 0x000000010ff84b84 in dbaui::OApplicationSwapWindow::selectContainer () #32 0x000000010ff86c5d in dbaui::OApplicationView::selectContainer () #33 0x000000010ff5cd17 in dbaui::OApplicationController::select () #34 0x000000010ff5d450 in non-virtual thunk to dbaui::OApplicationController::select(com::sun::star::uno::Any const&) () #35 0x000000010e2349b4 in dbaxml::DBContentLoader::load () #36 0x000000010c5de38d in framework::LoadEnv::impl_loadContent () #37 0x000000010c5d9f67 in framework::LoadEnv::startLoading () #38 0x000000010c5794e5 in framework::LoadDispatcher::impl_dispatch () #39 0x000000010c579a72 in framework::LoadDispatcher::dispatch () #40 0x00000001006f4cfd in implDispatchDelayed () #41 0x0000000102024136 in ImplWindowFrameProc () #42 0x00000001020301ab in AquaSalInstance::Yield () #43 0x0000000101d2a927 in ImplYield () #44 0x0000000101d2839c in Application::Execute () #45 0x0000000100073596 in desktop::Desktop::Main () #46 0x0000000101d2e914 in ImplSVMain () #47 0x000000010202feb6 in AquaSalInstance::handleAppDefinedEvent () #48 0x000000010206497e in -[VCL_NSApplication sendEvent:] () #49 0x00007fff9219d21a in -[NSApplication run] () #50 0x00007fff92141bd6 in NSApplicationMain () #51 0x000000010202f2ab in ImplSVMainHook () #52 0x0000000101d2f4aa in SVMain () #53 0x00000001000a0796 in soffice_main () #54 0x0000000100000f00 in main ()
I get a dialog showing the following on screen whenever the Base window opens after finishing the dialog creating an HSQLDB .odb, which I suspect could have the same root cause (same thing happens when reopening such a .odb): 'The connection to the data soource "Foo.odb" coud not be established. The connection to the externa data source could not be established. No SDBC driver was found for the given URL.' (The firebird issue might be related to some renamings of internal libraries that happened in the last few days, any chance you could re-test with a newer build? Firebird works fine for me.) I've tested using master from yesterday on commit: commit 7bc88db8c500b41fe926fb99cd403accd696e671 Author: Andrzej J.R. Hunt <andrzej@ahunt.org> Date: Tue Aug 27 20:52:37 2013 +0100 Implemet setNull. (firebird-sdbc) Change-Id: I9fd53a5e8b5d1dba467fa8064f9f2ea1b93f26df
(In reply to comment #4) > > I've tested using master from yesterday on commit: > > commit 7bc88db8c500b41fe926fb99cd403accd696e671 > Author: Andrzej J.R. Hunt <andrzej@ahunt.org> > Date: Tue Aug 27 20:52:37 2013 +0100 > > Implemet setNull. (firebird-sdbc) > > Change-Id: I9fd53a5e8b5d1dba467fa8064f9f2ea1b93f26df Will try again after a rebuild and keep you posted. Alex
I've managed to confirm that HSQLDB is in fact disabled -- this seems to have been a remnant of the SOLAR_JAVA->ENABLE_JAVA conversion, a patch for this is in gerrit: https://gerrit.libreoffice.org/#/c/5666/ I don't know whether or not this fixes the crash here though: on Linux at least a dialog is shown if the driver can't be loaded -- if this does in fact fix the crash then we should probably still fix the code as to not crash if a driver can't be loaded.
The stack trace looks like an abort caused by an unexpected exception being thrown, something I'd expect only in debug builds. Anyway, it is rather hard to investigate the abort/crash part of it without knowing which exception is thrown from where. OSDBCDriverManager::getDriverByURL promises to throw only RuntimeException (or derived classes), so probably the exception is thrown by something called by (something called by something called by ...) implGetDriverForURL, which makes no promises on what exceptions it does or does not throw. So the exception is not allowed to leave OSDBCDriverManager::getDriverByURL, and the program aborts instead. The way to find out would be to run under a debugger and break on exceptions being thrown. E.g. for gdb something like: break drivermanager::OSDBCDriverManager::getDriverByURL continue -------> when it enters drivermanager::OSDBCDriverManager::getDriverByURL catch throw continue
(In reply to comment #6) > I've managed to confirm that HSQLDB is in fact disabled -- this seems to > have been a remnant of the SOLAR_JAVA->ENABLE_JAVA conversion, a patch for > this is in gerrit: https://gerrit.libreoffice.org/#/c/5666/ Andrzej, I have applied that patch and after "make dev-install", I still cannot open embbedded HSQLDB database...
(In reply to comment #8) > Andrzej, I have applied that patch and after "make dev-install", I still > cannot open embbedded HSQLDB database... I had to do a make 'postprocess.clean' followed 'make dev-install' for this to work. I'm unsure of the exact reasons but a pure 'make dev-install' failed to get the driver working for me.
Still crashing for me with this build from yesterday : Version: 4.2.0.0.alpha0+ Build ID: 4bfc4a51fe0c88472de6580edf7002031855eae3 Alex
(In reply to comment #10) Ah, hadn't read all the exchanges in between, sorry, for that last redundant comment. Will try and produce a debug build, but don't hold your hopes up too much. Alex
On pc Debian x86-64 with master sources updated yesterday (commit 0c7e4656702a2e9e90cbb9e12f0bfeccafc472a6) + a brand new LO profile, I've been able to go until the end of the wizard. But then I've got this popup: The connection to the data source "test" could not be established. SQL Status: HY000 The connection to the external data source could not be established. No SDBC driver was found for the given URL. A connection for the following URL was requested "sdbc:embedded:hsqldb". (nothing special on console logs)
(In reply to comment #12) > On pc Debian x86-64 with master sources updated yesterday (commit > 0c7e4656702a2e9e90cbb9e12f0bfeccafc472a6) + a brand new LO profile, I've > been able to go until the end of the wizard. > But then I've got this popup: > > The connection to the data source "test" could not be established. > SQL Status: HY000 > > The connection to the external data source could not be established. No SDBC > driver was found for the given URL. > > A connection for the following URL was requested "sdbc:embedded:hsqldb". > > (nothing special on console logs) Just to confirm, did you definitely do: make postprocess.clean make dev-install (Alternatively a make clean should but might not have the same effect)
Nope I just had runned a make clean && make dev-install I launch "make postprocess.clean && make clean && make dev-install" tomorrow.
(In reply to comment #14) > Nope I just had runned a make clean && make dev-install > I launch "make postprocess.clean && make clean && make dev-install" tomorrow. There shouldn't be any need for a further make clean, but I definitely had to do a make postprocess.clean && make dev-install (i.e. you won't have to rebuild everything) -- it seems that make clean doesn't affect whatever make postprocess does and vice-versa.
Ok after having updated (commit f6fcc5b79ca72e0145b1798bbfa3d686bdf07042)+ make postprocess.clean + make clean + make dev-install, I don't reproduce this. I'm glad it worked but am very astonished that "make clean" wasn't sufficient.
Using build Version: 4.2.0.0.alpha0+ Build ID: d9b62a48d75e596888fcf10f5f73fed93e7b88a3 The wizard no longer crashes on embedded hsqldb creation. It still crashes on firebirddb creation, and I will open a separate issue for that with bt. Alex
I think there is still the underlying issue that should be fixed that OSDBCDriverManager::getDriverByURL crashes if a driver can't be loaded, which seems to happen only on Mac but not on other systems. I'll try and get a debug build of one of the commits where hsqldb was still broken to diagnose the reason for this.