Bug 79178

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