Bug 90614 - Base 4.4.2 - full crash on open table
Summary: Base 4.4.2 - full crash on open table
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.4.2.2 release
Hardware: x86 (IA32) All
: high critical
Assignee: Lionel Elie Mamane
URL:
Whiteboard: target:5.0.0 target:4.4.4
Keywords: haveBacktrace, regression
: 91224 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-04-14 15:53 UTC by mhonline
Modified: 2015-05-14 16:32 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
LO 442: destructive odb (49.91 KB, application/vnd.oasis.opendocument.database)
2015-04-24 13:42 UTC, mhonline
Details
bt with debug symbols (7.90 KB, text/plain)
2015-04-24 19:15 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mhonline 2015-04-14 15:53:13 UTC
I have a base-file containing abt 5. tables.
opening it on 4.4.0(portable) / JVM 1.7.75 /Vista:: all works fine
opening it on 4.4.2(portable) / JVM 1.7.75 (common files) / Win7(32)::Crash 
- part of the tables are working
- at least one table results in immidiate full crash of LO (with dataloss of that session in the other/working tables)

martin
Comment 1 Julien Nabet 2015-04-14 16:11:12 UTC
Which kind of DB do you use? (hsqldb embed, Mysql, Firebird, other?)
Comment 2 Julien Nabet 2015-04-14 17:47:35 UTC
Since it's unconfirmed and we're waiting for info, let's decrease importance for the moment.
Comment 3 raal 2015-04-15 05:20:03 UTC
Hello,

Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Comment 4 mhonline 2015-04-15 19:30:20 UTC
hsqldb embedded
I installed LO 442 parallel on the machine (Vista), where LO 440 was working 
same rusult: crash 
so it is related to 4.4.2
Base-File is availabe on PM .. just call

martin
Comment 5 Julien Nabet 2015-04-15 20:56:29 UTC
Thank you for your feedback.

Don't hesitate to use https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission to remove any confidential/private part.
It's far more practical to have a public attachment.

If interested, you may provide backtrace (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:_How_to_get_a_backtrace)
Comment 6 mhonline 2015-04-24 13:42:45 UTC
Created attachment 115051 [details]
LO 442: destructive odb
Comment 7 mhonline 2015-04-24 13:44:48 UTC
attached the destructive odb
tables working
form "event" results in immidiate crash (under 4.4.2)

pls note: this is for testing only and not intended for circulation (private property)

rgds
martin
Comment 8 raal 2015-04-24 15:05:27 UTC
I can confirm crash with Version: 5.0.0.0.alpha1+
Build ID: badec7478035008f514e0976a94438fe2e32dc40
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-04-22_01:28:24

No crash with LO 4.3.3, regression
Comment 9 Robert Großkopf 2015-04-24 17:42:56 UTC
I have found the reason:
There is a wrong designed listfield in the form mhf_event-data. The listfield txtmhfeventlocation point to bounded field 1. So there must be 2 fields defined in the SQL-Code. 
0 = the field, which should be shown
1 = the field, which should be saved or read from the form.

You could also change the bounded field to "0" - the form will work.

With LO 4.3.7.2 on OpenSUSE 13.2 64bit rpm Linux I got the crash without changing this. When changed the listfield as described I couldn't reproduce any crash.
Comment 10 Julien Nabet 2015-04-24 19:15:08 UTC
Created attachment 115077 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I could reproduce this.
Comment 11 Julien Nabet 2015-04-24 19:20:30 UTC
Lionel: the bt I attached shows a infinite recursive call to makeAny method. Of course, once the stack is full, it crashes.
Noticing http://cgit.freedesktop.org/libreoffice/core/commit/?id=61439adce623ce2e66d9f009f877e165b62f2051, you might be interested in this bugtracker.
Comment 12 Julien Nabet 2015-04-24 19:28:15 UTC
Just for information, getTypeKind returns 0, see http://opengrok.libreoffice.org/xref/core/connectivity/source/commontools/FValue.cxx#881
Comment 13 Commit Notification 2015-04-25 17:40:43 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=062c3afd4e829692cf022c5011b2a226d21c35e4

tdf#90614 oups... I was too eager in replacing getAny() with makeAny()

It will be available in 5.0.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.
Comment 14 mhonline 2015-04-25 22:01:53 UTC
@robert
thanks,  that worked, so the fieldcounter starts at 0 - good to know

martin
Comment 15 Commit Notification 2015-04-27 21:24:51 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=462a22db365551c376ca8d719911305dd68d98eb&h=libreoffice-4-4

tdf#90614 oups... I was too eager in replacing getAny() with makeAny()

It will be available in 4.4.4.

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 16 Robert Großkopf 2015-05-14 16:32:29 UTC
*** Bug 91224 has been marked as a duplicate of this bug. ***