Issue 126655 - AOO crashes with Firebird's ODBC driver
Summary: AOO crashes with Firebird's ODBC driver
Status: CONFIRMED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: 4.1.2
Hardware: Other Linux 64-bit
: P5 (lowest) Normal (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: crash
Depends on:
Blocks:
 
Reported: 2015-11-14 16:28 UTC by diego
Modified: 2017-11-17 05:04 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
ERROR (226.18 KB, image/png)
2015-11-14 16:28 UTC, diego
no flags Details
test.odb (1.63 KB, application/vnd.sun.xml.base)
2015-11-16 10:38 UTC, diego
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description diego 2015-11-14 16:28:58 UTC
Created attachment 85132 [details]
ERROR

I had success in creation of ODBC connection, but when I try creating one table occurred the error of screen shot.
Comment 1 diego 2015-11-14 16:31:07 UTC
OpenOffice version: 4.1.2
Comment 2 diego 2015-11-14 16:35:37 UTC
on the screen shot this described that the file will be recovered
Comment 3 orcmid 2015-11-14 17:08:44 UTC
(In reply to diego from comment #2)
> on the screen shot this described that the file will be recovered

This is a standard error message: 

"OpenOffice failed due to an unexpected error. All work on open files will be saved now. The next time the OpenOffice starts, your files will be recovered automatically. The following files will be recovered: test.odb"

Was the file recovered?  Or did recovery fail?

Had you been successful in this effort prior to Apache OpenOffice 4.1.2?

Can you upload the test.odb file?  It will be useful to inspect for anything that might help replicate the failure and isolate the difficulty.
Comment 4 oooforum (fr) 2015-11-16 08:54:58 UTC
What kind of database did you used?
ODBC is for Windows. With Linux, try another driver like JDBC or SDBC.

For me, it's not a P1 and not a blocker.

Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue.
Comment 5 diego 2015-11-16 10:23:48 UTC
(In reply to oooforum from comment #4)
> What kind of database did you used?
> ODBC is for Windows. With Linux, try another driver like JDBC or SDBC.
> 
> For me, it's not a P1 and not a blocker.
> 
> Read all comments and provide any requested information
> 
> Once all of this is done, please set the bug back to UNCONFIRMED and we will
> attempt to reproduce the issue.

I tried the unixODBC (ODBC for LINUX), I believe that the resource should run with success but I will try other way if I have not success with the unixODBC.

Official site with the procedure (unixODBC):

https://help.ubuntu.com/community/ODBC
Comment 6 diego 2015-11-16 10:38:23 UTC
Created attachment 85135 [details]
test.odb
Comment 7 diego 2015-11-16 10:46:52 UTC
(In reply to orcmid from comment #3)
> (In reply to diego from comment #2)
> > on the screen shot this described that the file will be recovered
> 
> This is a standard error message: 
> 
> "OpenOffice failed due to an unexpected error. All work on open files will
> be saved now. The next time the OpenOffice starts, your files will be
> recovered automatically. The following files will be recovered: test.odb"
> 
> Was the file recovered?  Or did recovery fail?
> 
> Had you been successful in this effort prior to Apache OpenOffice 4.1.2?
> 
> Can you upload the test.odb file?  It will be useful to inspect for anything
> that might help replicate the failure and isolate the difficulty.

Was the file recovered?  Or did recovery fail?
Yes, but the error occurred again.

Had you been successful in this effort prior to Apache OpenOffice 4.1.2?
I've been tried the openoffice 4.1.1, but o same error occurred then I updated for openoffice 4.1.2
Comment 8 diego 2015-11-16 10:49:13 UTC
(In reply to diego from comment #7)
> (In reply to orcmid from comment #3)
> > (In reply to diego from comment #2)
> > > on the screen shot this described that the file will be recovered
> > 
> > This is a standard error message: 
> > 
> > "OpenOffice failed due to an unexpected error. All work on open files will
> > be saved now. The next time the OpenOffice starts, your files will be
> > recovered automatically. The following files will be recovered: test.odb"
> > 
> > Was the file recovered?  Or did recovery fail?
> > 
> > Had you been successful in this effort prior to Apache OpenOffice 4.1.2?
> > 
> > Can you upload the test.odb file?  It will be useful to inspect for anything
> > that might help replicate the failure and isolate the difficulty.
> 
> Was the file recovered?  Or did recovery fail?
> Yes, but the error occurred again.
> 
> Had you been successful in this effort prior to Apache OpenOffice 4.1.2?
> I've been tried the openoffice 4.1.1, but o same error occurred then I
> updated for openoffice 4.1.2

obs.: test.odb file attached.
Comment 9 oooforum (fr) 2015-11-17 10:12:09 UTC
Thanks to reply at my comment 4
- What kind of database did you used?
- Did you tried another driver like JDBC or SDBC?
Comment 10 diego 2015-11-17 11:13:16 UTC
(In reply to oooforum from comment #9)
> Thanks to reply at my comment 4
> - What kind of database did you used?
> - Did you tried another driver like JDBC or SDBC?

- What kind of database did you used?

Answer: Firebird v1.5 Super Server with support NTPL

- Did you tried another driver like JDBC or SDBC?

Answer: No, I didn't try JDBC or SDBC because the UnixODBC connection works, is the OppenOffice.Org Base that did show error
Comment 11 damjan 2017-11-16 05:15:36 UTC
(In reply to oooforum (fr) from comment #4)
> What kind of database did you used?
> ODBC is for Windows. With Linux, try another driver like JDBC or SDBC.
> 

No. ADO is for Windows. ODBC is cross-platform.
Comment 12 damjan 2017-11-16 05:21:54 UTC
I am confirming, as I can easily crash AOO with the ODBC driver for Firebird, just by clicking on "Tables".

The crash happens as Firebird's ODBC driver returns an infinitely long string for a table name (on the "help" example database), that first hangs AOO with 100% CPU usage and eventually depletes all memory and results in a segfault as a main/sal string tries to write to unallocated memory:

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
0x00007f9d8a326850 in rtl_uString_new_WithLength (ppThis=0x7ffe9831e3b8, nLen=1064828930) at strtmpl.c:1043
1043	        (*ppThis)->length   = 0;
(gdb) bt
#0  0x00007f9d8a326850 in rtl_uString_new_WithLength (ppThis=0x7ffe9831e3b8, nLen=1064828930) at strtmpl.c:1043
#1  0x00007f9d8a3293f7 in rtl_uStringbuffer_ensureCapacity (This=0x7ffe9831e500, capacity=0x7ffe9831e508, minimumCapacity=532416495) at ustrbuf.c:92
#2  0x00007f9d8a3294c1 in rtl_uStringbuffer_insert (This=0x7ffe9831e500, capacity=0x7ffe9831e508, offset=532414464, str=0x7f9d74873010, len=2031) at ustrbuf.c:116
#3  0x00007f9d4ce420e4 in rtl::OUStringBuffer::append (this=0x7ffe9831e500, str=0x7f9d74873010, len=2031) at /AOO/main/solver/420/unxlngx6/inc/rtl/ustrbuf.hxx:339
#4  0x00007f9d4ce42099 in rtl::OUStringBuffer::append (this=0x7ffe9831e500, str=...) at /AOO/main/solver/420/unxlngx6/inc/rtl/ustrbuf.hxx:304
#5  0x00007f9d4ce413fe in connectivity::odbc::OTools::getStringValue (_pConnection=0x7f9d58141c50, _aStatementHandle=0x16d3410, columnIndex=2, _fSqlType=12, _bWasNull=@0x7f9d59f0c782: 0 '\000', _xInterface=..., _nTextEncoding=76)
    at /AOO/main/connectivity/source/drivers/odbcbase/OTools.cxx:651
#6  0x00007f9d4ce448bd in connectivity::odbc::ODatabaseMetaDataResultSet::getString (this=0x7f9d59f0c588, columnIndex=2) at /AOO/main/connectivity/source/drivers/odbcbase/ODatabaseMetaDataResultSet.cxx:430
#7  0x00007f9d5b9b0af2 in dbaccess::OFilteredContainer::construct (this=0x7f9d4dd728f8, _rTableFilter=..., _rTableTypeFilter=...) at /AOO/main/dbaccess/source/core/api/FilteredContainer.cxx:376
#8  0x00007f9d5ba73a80 in dbaccess::OConnection::refresh (this=this@entry=0x7f9d59ef0818, _rToBeRefreshed=...) at /AOO/main/dbaccess/source/core/dataaccess/connection.cxx:634
#9  0x00007f9d5ba73496 in dbaccess::OConnection::getTables (this=0x7f9d59ef0818) at /AOO/main/dbaccess/source/core/dataaccess/connection.cxx:663
...

I'll investigate in more detail later.
Comment 13 damjan 2017-11-17 05:04:08 UTC
The problem seems to be that Firebird's ODBC driver is trying to report a NULL string column by returning -1 (= SQL_NULL_DATA) in the lowest 32 bits of the 64 bit final (StrLen_or_IndPtr) argument passed to SQLGetData(), while filling the highest 32 bits with 0, resulting in 0x00000000FFFFFFFF = 4294967295, instead of -1, so we can't tell the column is null and keep appending rubbish to our string buffer until we run out of memory:

initial SQLGetData(0x1df7530,2,SQL_C_CHAR,0x7ffc8c02e200,2047,4294967295) = 0
subsequent SQLGetData(0x1df7530,2,SQL_C_CHAR,0x7ffc8c02e200,2047,4294967295) = 0
subsequent SQLGetData(0x1df7530,2,SQL_C_CHAR,0x7ffc8c02e200,2047,4294967295) = 0
subsequent SQLGetData(0x1df7530,2,SQL_C_CHAR,0x7ffc8c02e200,2047,4294967295) = 0
subsequent SQLGetData(0x1df7530,2,SQL_C_CHAR,0x7ffc8c02e200,2047,4294967295) = 0
subsequent SQLGetData(0x1df7530,2,SQL_C_CHAR,0x7ffc8c02e200,2047,4294967295) = 0
subsequent SQLGetData(0x1df7530,2,SQL_C_CHAR,0x7ffc8c02e200,2047,4294967295) = 0
...

I'll see what other ODBC drivers do.