Download it now!
Bug 53557 - CRASH - Form based on query with calculated field crashes Base
Summary: CRASH - Form based on query with calculated field crashes Base
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: x86-64 (AMD64) All
: high critical
Assignee: Lionel Elie Mamane
URL:
Whiteboard: target:3.7.0 target:3.6.2 target:3.5.7
Keywords: regression
: 54158 54631 (view as bug list)
Depends on:
Blocks: mab3.5 mab3.6
  Show dependency treegraph
 
Reported: 2012-08-15 20:23 UTC by pfreeman99
Modified: 2012-09-24 08:18 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
JVM stack trace (105.25 KB, text/x-log)
2012-08-19 12:14 UTC, Alex Thurgood
Details
Test DB to reproduce the problem (16.29 KB, application/vnd.oasis.opendocument.database)
2012-08-19 12:24 UTC, Alex Thurgood
Details
bt + console logs on master (12.96 KB, text/plain)
2012-08-20 21:33 UTC, Julien Nabet
Details
bt + console logs on master following previous comment (14.70 KB, text/plain)
2012-08-20 21:41 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pfreeman99 2012-08-15 20:23:05 UTC
I just updated to 3.6 from 3.5.6 and am having some trouble with some of my base forms.  I've got one form in particular that I've been able to produce a constant crash.  It's based on an SQL query (connected to a PostgreSQL backend).

This query crashes Libre as soon as I orun the query (either in the form, or in the query design screen):

SELECT "position"."pos_id", "position"."reports_to", "position"."pos_ref" || ' - ' || "position"."title" AS "ref_title" FROM "public"."position" AS "position"

This query works fine:

SELECT "position"."pos_id", "position"."reports_to", "position"."pos_ref" AS "ref_title" FROM "public"."position" AS "position"


The only difference is in the first one, I'm combining two fields into one using the || symbol.


I have other forms that populate fields with this pipe symbol that don't seem to be affected when I view the form, but if I run those same queries through the query design screen, it crashes.

These all worked without problems in 3.5.6.

Thanks.
Comment 1 Alex Thurgood 2012-08-19 11:50:40 UTC
(In reply to comment #0)

Hi,

> 
> The only difference is in the first one, I'm combining two fields into one
> using the || symbol.
> 


If you use CONCAT() instead of ||, can you get them to work without crashing ?


Alex
Comment 2 Alex Thurgood 2012-08-19 12:02:20 UTC
Confirming after testing on a hsqldb test database and adapting the query to my own dataset.


The console returns the following

*** glibc detected *** /opt/libreoffice3.6/program/soffice.bin: free(): invalid next size (fast): 0x0000000003692c60 ***


Alex
Comment 3 Alex Thurgood 2012-08-19 12:05:01 UTC
Tested on Version 3.6.0.4 (Build ID: 932b512) 64bit
Comment 4 Alex Thurgood 2012-08-19 12:10:49 UTC
alex@Aspire-T180 ~ $ /opt/libreoffice3.6/program/soffice
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f912661c1d0, pid=5738, tid=140261415860480
#
# JRE version: 6.0_26-b03
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libuno_cppu.so.3+0x151d0]  uno_type_any_assign+0xe0
#
# An error report file with more information is saved as:
# /home/alex/hs_err_pid5738.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

[error occurred during error reporting , id 0xb]
Comment 5 Alex Thurgood 2012-08-19 12:14:20 UTC
Created attachment 65774 [details]
JVM stack trace
Comment 6 Alex Thurgood 2012-08-19 12:16:22 UTC
@Lionel : assigning to you, if you can take it, otherwise please re-assign
Comment 7 Alex Thurgood 2012-08-19 12:22:38 UTC
No crash with :

LibreOffice 3.5.5.2 
Build ID: 24b32b4-b87ec2e-85c8e98-87a4e20-9a1b8c1


Setting regression keyword.
Comment 8 Alex Thurgood 2012-08-19 12:24:30 UTC
Created attachment 65775 [details]
Test DB to reproduce the problem
Comment 9 Alex Thurgood 2012-08-19 12:25:43 UTC
How to reproduce :

1) open the test db file attached to issue
2) click on the Queries button in the left hand pane
3) double click on Query1
Comment 10 Julien Nabet 2012-08-20 21:33:47 UTC
Created attachment 65851 [details]
bt + console logs on master

On pc Debian x86-64 with master sources updated today, I reproduced the problem.

Noticed this:
  1447         // Fetch the columns only once and in order, to satisfy restrictive backends such as ODBC
   1448         const int cc = m_xSetMetaData->getColumnCount();
   1449         connectivity::ORowVector< ORowSetValue >::Vector::iterator aFRIter = aFullRow->get().begin();
   1450         // Column 0 is reserved for the bookmark; unused here.
   1451         ++aFRIter;
   1452         BOOST_STATIC_ASSERT(sizeof(int) >= sizeof(sal_Int32)); // "At least a 32 bit word expected"
   1453         for (int i = 1; i <= cc; ++i, ++aFRIter )
   1454         {
   1455             aFRIter->fill(i, m_xSetMetaData->getColumnType(i), m_xDriverRow);
   1456         }

I rather propose this:
for (int i = 1; i < cc; ++i, ++aFRIter )

I tested but it crashes too for another reason.
Comment 11 Julien Nabet 2012-08-20 21:41:07 UTC
Created attachment 65852 [details]
bt + console logs on master following previous comment

With the "naive" patch from previous comment, here's the new bt and console logs.
Comment 12 Julien Nabet 2012-08-28 20:53:30 UTC
*** Bug 54158 has been marked as a duplicate of this bug. ***
Comment 13 Vince Radice 2012-08-31 04:48:35 UTC
I have followed the chain from my initial problem to here as it is marked as a dup of this one.  I don't understand the last comment here about being a dup.  Is looks to me as if the problem number in the dup comment has been crossed out.  Is that true or is it being formatted strangely on my pc?

This problem concerns SQL with || in the code.  I have looked at the failing forms.  All use the same query as a data source.  I looked at the query and there are no || in it.  However, there is a calculated field that is the quotient of two of the fields.  If I remove that from the query SQL, it runs and does not crash.  Is division of two fields supported while doing a query?  Could this be the cause of the segmentation fault?
Thank you,
Vince Radice
Comment 14 Lionel Elie Mamane 2012-08-31 05:19:32 UTC
(In reply to comment #13)
> I have followed the chain from my initial problem to here as it is marked as a
> dup of this one.  I don't understand the last comment here about being a dup. 
> Is looks to me as if the problem number in the dup comment has been crossed
> out.  Is that true or is it being formatted strangely on my pc?

Closed bugs are crossed out, so that one can immediately see that they are closed. A bug that has been found to be a duplicate of another one is closed, with closing reason "is a duplicate". The reason for that IMHO is to steer people towards the one bug that stays open among the duplicates.

That's why it appears crossed out.

> This problem concerns SQL with || in the code.  I have looked at the failing
> forms.  All use the same query as a data source.  I looked at the query and
> there are no || in it.  However, there is a calculated field that is the
> quotient of two of the fields.  If I remove that from the query SQL, it runs
> and does not crash.  Is division of two fields supported while doing a query?

It should. Doesn't work --> bug.

I understand that the bug is not specific to || or division, but more general on calculated field. Adapting summary.
Comment 15 Lionel Elie Mamane 2012-08-31 15:24:35 UTC
(In reply to comment #10)
> Created attachment 65851 [details]
> bt + console logs on master

> Noticed this:
>   1447         // Fetch the columns only once and in order, to satisfy
> restrictive backends such as ODBC
>    1448         const int cc = m_xSetMetaData->getColumnCount();
>    1449         connectivity::ORowVector< ORowSetValue >::Vector::iterator
> aFRIter = aFullRow->get().begin();
>    1450         // Column 0 is reserved for the bookmark; unused here.
>    1451         ++aFRIter;
>    1452         BOOST_STATIC_ASSERT(sizeof(int) >= sizeof(sal_Int32)); // "At
> least a 32 bit word expected"
>    1453         for (int i = 1; i <= cc; ++i, ++aFRIter )
>    1454         {
>    1455             aFRIter->fill(i, m_xSetMetaData->getColumnType(i),
> m_xDriverRow);
>    1456         }
> 
> I rather propose this:
> for (int i = 1; i < cc; ++i, ++aFRIter )

No. getColumnCount returns the number of columns EXCLUDING the bookmark column (column 0). In other words, the number of *real* data columns. The columns are thus numbered from 1 to cc, and the condition i <=cc is CORRECT.

Rather, getColumnCount() returns an incorrect result or something like that.
Comment 16 Not Assigned 2012-08-31 16:18:51 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=cdadb1b4fb207392961a24788d44bd7ffa529046

fdo#53557: use metadata's idea of column count to allocate a row
Comment 17 Lionel Elie Mamane 2012-08-31 16:25:00 UTC
(In reply to comment #15)
> (In reply to comment #10)

> No. getColumnCount returns the number of columns EXCLUDING the bookmark column
> (column 0). In other words, the number of *real* data columns. The columns are
> thus numbered from 1 to cc, and the condition i <=cc is CORRECT.

> Rather, getColumnCount() returns an incorrect result or something like that.

Actually, this code assumed
 m_xSetMetaData->getColumnCount()==m_pColumnNames->size()
but this is not true, because m_pColumnNames contains only columns that come from a table, not calculated columns.

So we just need to allocate aFullRow with m_xSetMetaData->getColumnCount() columns instead of m_pColumnNames->size() columns. (No, not "+1" for the bookmark column (column number 0), because the constructor of ORowVector takes care of this "+1":

connectivity/inc/connectivity/CommonTools.hxx:732

        ORowVector(size_t _st) : ORefVector< VectorVal >(_st+1)
            {}


That is now committed to master and asked backport to 3.6.
Comment 18 Julien Nabet 2012-08-31 21:11:04 UTC
Thank you Lionel, I updated master sources today and don't reproduce the problem anymore.
Comment 19 Roman Eisele 2012-09-03 08:25:34 UTC
Set Version field according to comments.
Comment 20 Roman Eisele 2012-09-03 08:29:11 UTC
This is a "LibO 3.6 most annoying bug", of course. But I don’t understand why this bug is also on our "LibO 3.5 most annoying bugs" list. Can we remove it from that list (bug 37361) -- or does this bug already appear in LibO 3.5.x? Then it would be good to have a comment explaining this ... Thanks!
Comment 21 Lionel Elie Mamane 2012-09-03 08:58:08 UTC
(In reply to comment #20)
> This is a "LibO 3.6 most annoying bug", of course. But I don’t understand why
> this bug is also on our "LibO 3.5 most annoying bugs" list. Can we remove it
> from that list (bug 37361) -- or does this bug already appear in LibO 3.5.x?

Affected/buggy code is in 3.5 branch, but after 3.5.6 branch. So unless we backport the fix, 3.5.7 will have this bug.
Comment 22 Vince Radice 2012-09-03 16:16:12 UTC
If there is a fix for this problem, how do I get it and install it?  Will there be a new version to download?  Can I update just the failing module?
Thanks. Vince Radice
Comment 23 Julien Nabet 2012-09-03 17:08:02 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > This is a "LibO 3.6 most annoying bug", of course. But I don’t understand why
> > this bug is also on our "LibO 3.5 most annoying bugs" list. Can we remove it
> > from that list (bug 37361) -- or does this bug already appear in LibO 3.5.x?
> 
> Affected/buggy code is in 3.5 branch, but after 3.5.6 branch. So unless we
> backport the fix, 3.5.7 will have this bug.
BTW, what about 3.6 branch? Could it be backported to it?
Comment 24 Lionel Elie Mamane 2012-09-03 20:16:31 UTC
(In reply to comment #23)
> (In reply to comment #21)

>> Affected/buggy code is in 3.5 branch, but after 3.5.6 branch. So unless we
>> backport the fix, 3.5.7 will have this bug.

> BTW, what about 3.6 branch? Could it be backported to it?

3.6: https://gerrit.libreoffice.org/#/c/522/

3.5: http://lists.freedesktop.org/archives/libreoffice/2012-September/037740.html


(In reply to comment #22)
> If there is a fix for this problem, how do I get it and install it?
> Will there be a new version to download?

Next version to go in each branch out should have the fix:

 3.7.0.alpha
 3.6.2.rc1
 3.5.7

In the meantime, the daily builds of master have the fix (but that's alpha code in general) and hopefully within a few days the daily builds of libreoffice-3-6 will have the fix, as soon as a fellow developer has reviewed the fix (these are at http://dev-builds.libreoffice.org/daily/Linux-x86_10-Release-Configuration/libreoffice-3-6/current/ and http://dev-builds.libreoffice.org/daily/Linux-x86_64_11-Release-Configuration/libreoffice-3-6/current/)

> Can I update just the failing module?

Possibly you can hack up something like that (copying just the right .so/.dylib/.dll file from a newer version), but I can't guarantee out of the top of my head it would work. There is no inlined function touched, so you have a good chance.
Comment 25 Julien Nabet 2012-09-03 21:42:43 UTC
(In reply to comment #24)
> > BTW, what about 3.6 branch? Could it be backported to it?
> 
> 3.6: https://gerrit.libreoffice.org/#/c/522/
> 
> 3.5:
> http://lists.freedesktop.org/archives/libreoffice/2012-September/037740.html
Had missed it, thank you Lionel!
Comment 26 Alex Thurgood 2012-09-07 10:33:36 UTC
*** Bug 54631 has been marked as a duplicate of this bug. ***
Comment 27 Not Assigned 2012-09-10 10:39:21 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f80d0c180c7e98caf211059f54873001f9e0a64e&g=libreoffice-3-6

fdo#53557: use metadata's idea of column count to allocate a row


It will be available in LibreOffice 3.6.2.

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 28 Not Assigned 2012-09-10 11:16:40 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=613c7a22a850a890a358d39cae43e97f31f516a5&g=libreoffice-3-5

fdo#53557: use metadata's idea of column count to allocate a row


It will be available in LibreOffice 3.5.7.

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 29 Michael Meeks 2012-09-10 11:17:30 UTC
so - since it's committed ~everywhere live ;-) I'm marking it fixed.

Thanks Lionel ! :-)
Comment 30 Vince Radice 2012-09-10 17:00:22 UTC
I updated to Version 3.6.2.0+ (Build ID: 8a861b9)

And tried again.  I got the same error as before:

Executable: soffice.bin PID: 5270 Signal: Segmentation fault (11)

The database that I uploaded in my bug report - 54158  - should still show the same error.  To reproduce the error run the query EarnPserv.  

If this query does not fail, please let me know and I will upload a database with the error.

If I have not got the right build, please let me know which build should have the fix.

Thank you
Comment 31 Vince Radice 2012-09-10 17:13:22 UTC
I updated to Version 3.6.2.0+ (Build ID: 8a861b9)

And tried again.  I got the same error as before:

Executable: soffice.bin PID: 5270 Signal: Segmentation fault (11)

The database that I uploaded in my bug report - 54158  - should still show the same error.  To reproduce the error run the query EarnPserv.  

If this query does not fail, please let me know and I will upload a database with the error.

If I have not got the right build, please let me know which build should have the fix.

Thank you
Comment 32 Vince Radice 2012-09-10 17:15:15 UTC
I updated to Version 3.6.2.0+ (Build ID: 8a861b9)

And tried again.  I got the same error as before:

Executable: soffice.bin PID: 5270 Signal: Segmentation fault (11)

The database that I uploaded in my bug report - 54158  - should still show the same error.  To reproduce the error run the query EarnPserv.  

If this query does not fail, please let me know and I will upload a database with the error.

If I have not got the right build, please let me know which build should have the fix.

Thank you
Comment 33 Vince Radice 2012-09-10 17:18:56 UTC
PC was acting up and I accidently submitted the same comment three times.  Can someone please remove the duplicates?  Sorry for the error.
Vince Radice
Comment 34 Vince Radice 2012-09-22 02:51:08 UTC
Updated to the version from Sept. 13.  All works fine.  
BTW - speed improvement is really good.  Thanks for all the work you have put into this product.
Comment 35 Alex Thurgood 2012-09-24 08:18:22 UTC
OP verified fixed.