Bug Hunting Session
Bug 79178 - Crash when opening a form created with a previous version
Summary: Crash when opening a form created with a previous version
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.3.0.0.alpha1
Hardware: Other All
: medium critical
Assignee: Caolán McNamara
URL:
Whiteboard: target:4.3.0
Keywords: haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2014-05-24 14:59 UTC by pierre-yves samyn
Modified: 2015-02-24 23:34 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
TestFormCrash.odb (2 forms) (19.91 KB, application/vnd.oasis.opendocument.database)
2014-05-24 14:59 UTC, pierre-yves samyn
Details
bt with symbols (18.17 KB, text/plain)
2014-05-24 22:53 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pierre-yves samyn 2014-05-24 14:59:13 UTC
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
Comment 1 Firas Hanife 2014-05-24 15:36:09 UTC
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
Comment 2 ribotb 2014-05-24 15:58:41 UTC
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
Comment 3 Julien Nabet 2014-05-24 22:53:31 UTC
Created attachment 99745 [details]
bt with symbols

On pc Debian x86-64 with master sources updated yesterday, I could reproduce this.
Comment 4 Julien Nabet 2014-05-24 23:15:55 UTC
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
Comment 5 Julien Nabet 2014-05-24 23:48:47 UTC
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.
Comment 6 Julien Nabet 2014-05-25 00:11:38 UTC
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)
Comment 7 pierre-yves samyn 2014-05-25 06:14:10 UTC
Hi

(In reply to comment #6)
> Here's a workaround.
> ...

I confirm the workaround. Well found Julien :)

Regards
Pierre-Yves
Comment 8 Julien Nabet 2014-05-25 08:22:36 UTC
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.
Comment 9 Julien Nabet 2014-05-25 09:37:11 UTC
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.
Comment 10 Caolán McNamara 2014-05-25 13:55:32 UTC
broke between a96b6f4708d587ddddd93101e51e52dec4e87b7e..e1b85e77b15a02d40049994e9829a0e3b921850c I believe
Comment 11 Commit Notification 2014-05-25 14:30:03 UTC
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.
Comment 12 Commit Notification 2014-05-25 14:31:35 UTC
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.
Comment 13 Jacques Guilleron 2014-05-25 15:32:24 UTC
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
Comment 14 ribotb 2014-05-25 16:00:46 UTC
I have also databases with reports that causes the crash of LO.

Bernard
Comment 15 ribotb 2014-06-20 21:43:50 UTC
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
Comment 16 pierre-yves samyn 2014-06-21 06:15:17 UTC
Hi

I confirm no crash on windows 7/64 & Version: 4.3.0.1
Build ID: 67f5430184326974072b65403ef1d9d934fc4481

Thank you
Regards
Pierre-Yves
Comment 17 Julien Nabet 2014-06-21 06:17:07 UTC
Following last comments, let's put this one to VERIFIED