Bug 79714 - OSX - crash opening query or table in embedded Firebird ODB
Summary: OSX - crash opening query or table in embedded Firebird ODB
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.3.0.0.beta2
Hardware: x86-64 (AMD64) Mac OS X (All)
: highest blocker
Assignee: Not Assigned
URL:
Whiteboard: target:4.4.0 target:4.2.6 target:4.3.0.1
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-06 08:18 UTC by Alex Thurgood
Modified: 2014-06-12 08:25 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
stack trace (64.08 KB, text/plain)
2014-06-06 08:20 UTC, Alex Thurgood
Details
bt (11.58 KB, text/plain)
2014-06-06 08:44 UTC, Alex Thurgood
Details
bt with 4-4 (61.56 KB, text/plain)
2014-06-07 08:15 UTC, Julien Nabet
Details
bt with MacOs (15.35 KB, text/rtf)
2014-06-09 18:28 UTC, Julien Nabet
Details
Valgrind log (104.32 KB, text/x-log)
2014-06-10 19:27 UTC, Julien Nabet
Details
bt after patch (6.01 KB, text/rtf)
2014-06-10 20:15 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2014-06-06 08:18:16 UTC
While attempting to retest status of bug 74019, I downloaded the test file provided there and loaded it into my master build.

When I double click on good query, I get an immediate crash, Apple stack trace enclosed.
Comment 1 Alex Thurgood 2014-06-06 08:20:48 UTC
Created attachment 100510 [details]
stack trace
Comment 2 Alex Thurgood 2014-06-06 08:44:04 UTC
Created attachment 100514 [details]
bt
Comment 3 Alex Thurgood 2014-06-06 08:55:04 UTC
In fact, any aatempt to open a query or table causes the crash
Comment 4 Julien Nabet 2014-06-06 22:49:06 UTC
On pc Debian x86-64 with master sources updated yesterday, I don't reproduce this.
MacOS only bug?
Alex: what's the build date? If more than 1 week, could you give a try to a newer one?
Comment 5 Alex Thurgood 2014-06-06 22:50:56 UTC
Julien, yes, it is OSX only. My build dates from 04/06/2014
Comment 6 Julien Nabet 2014-06-06 22:54:19 UTC
Just if you have 4.3 or 4.2 in parallel (if not, don't bother), do you reproduce this too on 4.3/4.2 daily builds?
Comment 7 Alex Thurgood 2014-06-07 05:21:22 UTC
(In reply to comment #6)
> Just if you have 4.3 or 4.2 in parallel (if not, don't bother), do you
> reproduce this too on 4.3/4.2 daily builds?

On 4242 production release, it doesn't crash.
Comment 8 Julien Nabet 2014-06-07 08:15:28 UTC
Created attachment 100591 [details]
bt with 4-4

On MacOs 10.7.5 with 2014/06/07 daily build, I got a different bt.
Comment 9 Julien Nabet 2014-06-07 08:22:35 UTC
I got the same bt with 4.3 on MacOS
Comment 10 Julien Nabet 2014-06-07 08:34:17 UTC
Hum, in fact once I removed LO directory profile, I don't reproduce this with 4.3 daily build...
Comment 11 Alex Thurgood 2014-06-07 09:45:04 UTC
Still crashes for me on 10.9.2 with master, even after removing all LO profiles
Comment 12 Alex Thurgood 2014-06-07 09:46:46 UTC
Julien, are you using 32 or 64 bit versions of LO - mine are all 64bit ?
Comment 13 Alex Thurgood 2014-06-07 09:49:13 UTC
LO 4.3 beta 2 is 32bit
Comment 14 Alex Thurgood 2014-06-07 10:04:17 UTC
LO 4.3 beta 2 also crashes with same trace on OSX 10.9.2
Comment 15 Alex Thurgood 2014-06-07 10:07:49 UTC
I'm on OSX 10.9.3, not 10.9.2, as previously indicated
Comment 16 Lionel Elie Mamane 2014-06-09 04:53:21 UTC
exception std::bad_alloc means that the "new" operator failed to allocate memory... If you can attach a debugger and see what happens in OResultSetMetaData::getColumnName when the exception is thrown, it would be useful. Is suspect that m_pSqlda->sqlvar[column-1].sqlname_length contains an unreasonable value.
Comment 17 Julien Nabet 2014-06-09 18:02:39 UTC
After having built LO with master sources on MacOs (64bits build), I got a crash this:

warn:legacy.osl:522:1:connectivity/source/drivers/firebird/DatabaseMetaData.cxx:845: Not implemented yet!
warn:connectivity.firebird:522:1:connectivity/source/drivers/firebird/Util.cxx:243: Unknown type: 0
Assertion failed: (false), function mallocSQLVAR, file /Users/julien/lo/core/connectivity/source/drivers/firebird/Util.cxx, line 244.
warn:legacy.tools:522:1:vcl/source/window/dialog.cxx:794: Dialog::StartExecuteModal() - Parent not visible
Comment 18 Julien Nabet 2014-06-09 18:28:11 UTC
Created attachment 100763 [details]
bt with MacOs

First bt retrieved on MacOS with built sources! :)
Comment 19 Lionel Elie Mamane 2014-06-09 18:38:11 UTC
(In reply to comment #17)
> After having built LO with master sources on MacOs (64bits build), I got a
> crash this:
> 
> warn:connectivity.firebird:522:1:connectivity/source/drivers/firebird/Util.
> cxx:243: Unknown type: 0

That's the fatal one: wants to allocate memory for a SQL variable, but gets an unknown type, namely zero. Need to step through how  pSqlda is constructed in the *parent* in the backtrace (namely OStatementCommonBase::prepareAndDescribeStatement) to see how / why one gets a type if "0" (or 1, since the 1 bit is masked out).
Comment 20 Julien Nabet 2014-06-09 19:22:03 UTC
Adding some traces on connectivity/source/drivers/firebird/Statement.cxx in executeQuery, I got this on Linux:
 sql : SELECT DISTINCT indices.RDB$INDEX_NAME FROM RDB$INDICES indices JOIN RDB$INDEX_SEGMENTS index_segments ON (indices.RDB$INDEX_NAME = index_segments.RDB$INDEX_NAME) JOIN RDB$RELATION_FIELDS relation_fields ON (index_segments.RDB$FIELD_NAME = relation_fields.RDB$FIELD_NAME) JOIN RDB$FIELDS fields ON (relation_fields.RDB$FIELD_SOURCE = fields.RDB$FIELD_NAME) WHERE (indices.RDB$SYSTEM_FLAG = 0) AND ((fields.RDB$FIELD_TYPE = 14)      OR (fields.RDB$FIELD_TYPE = 37)) AND (indices.RDB$INDEX_INACTIVE IS NULL OR indices.RDB$INDEX_INACTIVE = 0) 
 m_pSqlda : 0
warn:legacy.osl:29078:1:connectivity/source/drivers/firebird/DatabaseMetaData.cxx:845: Not implemented yet!
 sql : SELECT RDB$RELATION_NAME, RDB$SYSTEM_FLAG, RDB$RELATION_TYPE, RDB$DESCRIPTION, RDB$VIEW_BLR FROM RDB$RELATIONS WHERE ( (0 = 1) OR (RDB$SYSTEM_FLAG IS NULL OR RDB$SYSTEM_FLAG = 0 AND RDB$VIEW_BLR IS NULL) OR (RDB$SYSTEM_FLAG IS NULL OR RDB$SYSTEM_FLAG = 0 AND RDB$VIEW_BLR IS NOT NULL) ) AND RDB$RELATION_NAME LIKE '%'  ORDER BY RDB$RELATION_TYPE, RDB$RELATION_NAME
 m_pSqlda : 0
 sql : SELECT RDB$RELATION_NAME, RDB$SYSTEM_FLAG, RDB$RELATION_TYPE, RDB$DESCRIPTION, RDB$VIEW_BLR FROM RDB$RELATIONS WHERE (RDB$RELATION_TYPE = 0 OR RDB$RELATION_TYPE = 1) AND RDB$RELATION_NAME = 'Exchange'  ORDER BY RDB$RELATION_TYPE, RDB$RELATION_NAME
 m_pSqlda : 0
 sql : SELECT relfields.RDB$RELATION_NAME, relfields.RDB$FIELD_NAME, relfields.RDB$DESCRIPTION,relfields.RDB$DEFAULT_VALUE, relfields.RDB$FIELD_POSITION, fields.RDB$FIELD_TYPE, fields.RDB$FIELD_LENGTH, fields.RDB$FIELD_PRECISION, relfields.RDB$NULL_FLAG FROM RDB$RELATION_FIELDS relfields JOIN RDB$FIELDS fields on (fields.RDB$FIELD_NAME = relfields.RDB$FIELD_SOURCE) WHERE (1 = 1) AND relfields.RDB$RELATION_NAME = 'Exchange' AND relfields.RDB$FIELD_NAME LIKE '%' 
 m_pSqlda : 0
 sql : SELECT * FROM "Exchange" WHERE 0 = 1
 m_pSqlda : 0
 sql : SELECT constr.RDB$RELATION_NAME, inds.RDB$FIELD_NAME, inds.RDB$FIELD_POSITION, constr.RDB$CONSTRAINT_NAME FROM RDB$RELATION_CONSTRAINTS constr JOIN RDB$INDEX_SEGMENTS inds on (constr.RDB$INDEX_NAME = inds.RDB$INDEX_NAME) WHERE constr.RDB$RELATION_NAME = 'Exchange' AND constr.RDB$CONSTRAINT_TYPE = 'PRIMARY KEY' ORDER BY inds.RDB$FIELD_NAME
 m_pSqlda : 0
Comment 21 Julien Nabet 2014-06-09 19:28:56 UTC
In comparison on MacOs, the last logs show:
sql : SELECT * FROM "Exchange" WHERE 0 = 1
m_pSqlda : 0
Comment 22 Julien Nabet 2014-06-09 20:41:32 UTC
After some tests, I noticed Debian x86-64 (Intel i5) was considered as OSL_BIGENDIAN
whereas MacOs 10.9.3, i5 too! wasn't considered as OSL_BIGENDIAN
so this could be the problem:
int dtype = (pVar->sqltype & ~1);

"~1" should be changed if not BIG_ENDIAN
Comment 23 Julien Nabet 2014-06-10 19:27:03 UTC
Created attachment 100839 [details]
Valgrind log

An interesting part:
==24845== Conditional jump or move depends on uninitialised value(s)
==24845==    at 0x4D59E54A: UTLD_parse_sql_info(long*, unsigned short, char const*, XSQLDA*, unsigned short*) (utld.cpp:234)
==24845==    by 0x4D3723BD: iterative_sql_info(long*, unsigned int*, unsigned short, char const*, short, char*, unsigned short, XSQLDA*) (why.cpp:5564)
==24845==    by 0x4D3690F0: isc_dsql_describe (why.cpp:2455)
==24845==    by 0x4D047744: connectivity::firebird::OStatementCommonBase::prepareAndDescribeStatement(rtl::OUString const&, XSQLDA*&, XSQLDA*) (StatementCommonBase.cxx:200)
==24845==    by 0x4D045E8D: connectivity::firebird::OStatement::executeQuery(rtl::OUString const&) (Statement.cxx:118)
Comment 24 Julien Nabet 2014-06-10 19:48:49 UTC
This patch:
diff --git a/connectivity/source/drivers/firebird/StatementCommonBase.cxx b/connectivity/source/drivers/firebird/StatementCommonBase.cxx
index 381b14b..49415fa 100644
--- a/connectivity/source/drivers/firebird/StatementCommonBase.cxx
+++ b/connectivity/source/drivers/firebird/StatementCommonBase.cxx
@@ -194,6 +194,7 @@ void OStatementCommonBase::prepareAndDescribeStatement(const OUString& sql,
         free(pOutSqlda);
         pOutSqlda = (XSQLDA*) malloc(XSQLDA_LENGTH(n));
         pOutSqlda->version = SQLDA_VERSION1;
+        pOutSqlda->sqln = n;
         aErr = isc_dsql_describe(m_statusVector,
                                  &m_aStatementHandle,
                                  1,
makes possible to open the 2 queries on MacOs but then LO crashes when closing.
Comment 25 Julien Nabet 2014-06-10 20:15:48 UTC
Created attachment 100840 [details]
bt after patch

Here's the bt I get after crash.
crash is quite hard since Ctrl-C doesn't work. I must open a new term and kill the process.
Comment 26 Commit Notification 2014-06-11 17:27:44 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0acd0ed3a58698a34e11dd82f3368a983f8530df

Related fdo#79714 OSX-crash opening query or table in embedded Firebird ODB



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 27 Julien Nabet 2014-06-11 17:35:36 UTC
Given this line:
pOutSqlda->sqln = 10;
(see http://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/firebird/StatementCommonBase.cxx#125), I think there's a link with fdo#74019
Comment 28 Julien Nabet 2014-06-11 17:38:47 UTC
I finally pushed this patch because:
- Valgrind is right (we can read this "pOutSqlda->sqln = 10;" line 138, see http://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/firebird/StatementCommonBase.cxx#125
- It allows to open both queries on MacOs
- The crash I had seems to concern debug build only
So now, it'll be interesting to wait for the next daily build to test this on non debug config.

Of course, whatever the result, we should take into account this problem in debug mode but I must recognize I'm quite stuck since I don't understand why the Firebird cleaning process fails :(

Lionel/Andrzej: any idea?
Comment 29 Julien Nabet 2014-06-11 18:34:43 UTC
I wonder if it could be a problem linked to the order of destructor calls in Firebird code.
Indeed, there're several classes related by inheritance. There's also template part which doesn't help me to understand the whole thing as an almost beginner C++ dev I am :)
Comment 30 Alex Thurgood 2014-06-12 06:15:22 UTC
Works for me too, and no crash on exit - brilliant !
Comment 31 Alex Thurgood 2014-06-12 06:16:50 UTC
As far as I'm concerned, you can set this to resolved fixed.
Comment 32 Julien Nabet 2014-06-12 06:23:47 UTC
Thank you Alex for the test!
So with:
- on master http://cgit.freedesktop.org/libreoffice/core/commit/?id=0acd0ed3a58698a34e11dd82f3368a983f8530df
- 4.3 https://gerrit.libreoffice.org/9741
- 4.2 https://gerrit.libreoffice.org/9742
 and according to your comment, let's put it as FIXED.
Comment 33 Alex Thurgood 2014-06-12 06:33:16 UTC
Ooops, having just checked my autogen, I'm not using dgbutil after all, so can not confirm that a debug build doesn't crash, but at least my normal build works ;-)
Comment 34 Commit Notification 2014-06-12 08:25:17 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8c46e9ddf071b6fa5db83276d82ca23d459e8193&h=libreoffice-4-2

Related fdo#79714 OSX-crash opening query or table in embedded Firebird ODB


It will be available in LibreOffice 4.2.6.

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 35 Commit Notification 2014-06-12 08:25:35 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=939c5b7c2421b226e555cfd14d35d699be787b32&h=libreoffice-4-3

Related fdo#79714 OSX-crash opening query or table in embedded Firebird ODB


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.