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.
Created attachment 100510 [details] stack trace
Created attachment 100514 [details] bt
In fact, any aatempt to open a query or table causes the crash
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?
Julien, yes, it is OSX only. My build dates from 04/06/2014
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?
(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.
Created attachment 100591 [details] bt with 4-4 On MacOs 10.7.5 with 2014/06/07 daily build, I got a different bt.
I got the same bt with 4.3 on MacOS
Hum, in fact once I removed LO directory profile, I don't reproduce this with 4.3 daily build...
Still crashes for me on 10.9.2 with master, even after removing all LO profiles
Julien, are you using 32 or 64 bit versions of LO - mine are all 64bit ?
LO 4.3 beta 2 is 32bit
LO 4.3 beta 2 also crashes with same trace on OSX 10.9.2
I'm on OSX 10.9.3, not 10.9.2, as previously indicated
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.
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
Created attachment 100763 [details] bt with MacOs First bt retrieved on MacOS with built sources! :)
(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).
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
In comparison on MacOs, the last logs show: sql : SELECT * FROM "Exchange" WHERE 0 = 1 m_pSqlda : 0
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
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)
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.
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.
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.
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
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?
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 :)
Works for me too, and no crash on exit - brilliant !
As far as I'm concerned, you can set this to resolved fixed.
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.
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 ;-)
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.
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.