Created attachment 99712 [details] TestFormCrash.odb (2 forms) Hello Crash when opening a form created with a previous version Steps to reproduce: 1. Open the attached database TestFormCrash.odb It contains a form "Clients" created with a previous version and a form "Clients2" created with 4.3.0 wizard. 2. Double click (or right click > Open ) on Clients2 Expected & actual result: the form opens 3. Double click (or right click > Open ) on Clients Expected result: the form opens Actual result: crash The same database works correctly with version Version: 4.2.4.2 The crash also occurs with other databases (not only the attached database) Also reproduce (qa-fr) on Windows 7/64 & Version: 4.3.0.0.beta1 Build ID: 2e39c7e59c8fc8b16a54c3d981dceef27fb0c07f So I set status to New Regards Pierre-Yves
I can reproduce this issue on openSUSE 13.1 with: LibreOffice 4.3.0.0.beta1 Build ID: 2e39c7e59c8fc8b16a54c3d981dceef27fb0c07f Works as expected with 4.1.6.2
Hello, I confirm this problem and I add some precisions: 1) the crash does not occur systematically with forms created in a previous version of LO (some forms can be open without crash); 2) the crash is independent of the access method to the tables (direct access, SQL commands, Queries); 3) it can occur even if there is no control in the form (empty form)! Regards, Bernard
Created attachment 99745 [details] bt with symbols On pc Debian x86-64 with master sources updated yesterday, I could reproduce this.
I don't know if there's a link with the crash but unzipping the odb file shows that only Client form does contain meta.xml
Here's what I got after a gdb debug session The pb is in XMLBasedAcceleratorConfiguration::reload see http://opengrok.libreoffice.org/xref/core/framework/source/accelerators/acceleratorconfiguration.cxx#223 More precisely line 243-245 of this part: 239 css::uno::Reference< css::io::XInputStream > xIn; 240 if (xStream.is()) 241 xIn = xStream->getInputStream(); 242 if (!xIn.is()) 243 throw css::io::IOException( 244 OUString("Could not open accelerator configuration for reading."), 245 static_cast< ::cppu::OWeakObject* >(this)); the static_cast doesn't seem to work here. Also, if we unwind from here. LO goes into this part with Client because: xStream.is() is false because of this part: 231 xStream = m_aPresetHandler.openTarget(PresetHandler::TARGET_CURRENT(), true); // sal_True => open or create! This part calls 591 css::uno::Reference< css::io::XStream > PresetHandler::openTarget(const OUString& sTarget , 592 bool bCreateIfMissing) see http://opengrok.libreoffice.org/xref/core/framework/source/accelerators/presethandler.cxx#590 but this method returns empty stream because m_xWorkingStorageUser is empty too.
Here's a workaround. unzip odb file and do this: - mkdir ./forms/Obj11/Configurations2/accelerator - touch ./forms/Obj11/Configurations2/accelerator/current.xml - in META-INF/manifest.xml, add this line <manifest:file-entry manifest:full-path="forms/Obj11/Configurations2/accelerator/current.xml" manifest:media-type=""/> in Obj11 block Rezip and rename in odb, it works. Lionel: any idea how to solve this? (I attached a bt + gdb session)
Hi (In reply to comment #6) > Here's a workaround. > ... I confirm the workaround. Well found Julien :) Regards Pierre-Yves
Jan: I saw in git history some commits about accelerators. I thought you might be interested since the form which make LO to crash doesn't contain accelerator.
I tried this patch: diff --git a/framework/source/accelerators/presethandler.cxx b/framework/source/accelerators/presethandler.cxx index f9ce7d4..5df2fde 100644 --- a/framework/source/accelerators/presethandler.cxx +++ b/framework/source/accelerators/presethandler.cxx @@ -599,7 +599,12 @@ css::uno::Reference< css::io::XStream > PresetHandler::openTarget(const OUString // e.g. module without any config data ?! if (!xFolder.is()) - return css::uno::Reference< css::io::XStream >(); + { + if (bCreateIfMissing) + m_xWorkingStorageUser = xFolder = getOrCreateRootStorageUser(); + else + return css::uno::Reference< css::io::XStream >(); + } OUString sFile(sTarget); sFile += ".xml"; The form doesn't crash. However, even if I modify the form, the accelerator part isn't created.
broke between a96b6f4708d587ddddd93101e51e52dec4e87b7e..e1b85e77b15a02d40049994e9829a0e3b921850c I believe
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=637bb5adf7593c26e17e83482e42ccb8fac845a8 Resolves: fdo#79178 Crash when opening a form created with a previous version 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.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=94f4d28eb4d0a2cb73581f1483f18bb072c81b4a&h=libreoffice-4-3 Resolves: fdo#79178 Crash when opening a form created with a previous version It will be available in LibreOffice 4.3. 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.
Hi all, Workaround can also concern reports. At this adress: http://www.biotechno.fr/Creer-et-gerer-une-base-de-donnees.html#creation-des-tables I found a bd with a form and a report which both crash LO 4.3.0.0.beta1 Build ID: 2e39c7e59c8fc8b16a54c3d981dceef27fb0c07f & Windows 7 Home Premium Form and report don't crash LO 4.2.4.2. Pierre-Yves noticed that the workaround in this case allows to open this report correctly. regards, Jacques
I have also databases with reports that causes the crash of LO. Bernard
Hi, It seems work correctly with 4.3.0.1 (I tried with some forms and reports). Version: 4.3.0.1 Build ID: 67f5430184326974072b65403ef1d9d934fc4481 Win 7/32bits Bernard
Hi I confirm no crash on windows 7/64 & Version: 4.3.0.1 Build ID: 67f5430184326974072b65403ef1d9d934fc4481 Thank you Regards Pierre-Yves
Following last comments, let's put this one to VERIFIED