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.
(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
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
Tested on Version 3.6.0.4 (Build ID: 932b512) 64bit
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]
Created attachment 65774 [details] JVM stack trace
@Lionel : assigning to you, if you can take it, otherwise please re-assign
No crash with : LibreOffice 3.5.5.2 Build ID: 24b32b4-b87ec2e-85c8e98-87a4e20-9a1b8c1 Setting regression keyword.
Created attachment 65775 [details] Test DB to reproduce the problem
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
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.
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.
*** Bug 54158 has been marked as a duplicate of this bug. ***
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
(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.
(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.
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
(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.
Thank you Lionel, I updated master sources today and don't reproduce the problem anymore.
Set Version field according to comments.
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!
(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.
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
(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?
(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.
(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!
*** Bug 54631 has been marked as a duplicate of this bug. ***
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.
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.
so - since it's committed ~everywhere live ;-) I'm marking it fixed. Thanks Lionel ! :-)
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
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
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.
OP verified fixed.