Apache OpenOffice (AOO) Bugzilla – Issue 126655
AOO crashes with Firebird's ODBC driver
Last modified: 2020-12-07 13:57:51 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.
OpenOffice version: 4.1.2
on the screen shot this described that the file will be recovered
(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.
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.
(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
Created attachment 85135 [details] test.odb
(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
(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.
Thanks to reply at my comment 4 - What kind of database did you used? - Did you tried another driver like JDBC or SDBC?
(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
(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.
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.
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.
*** Issue 112753 has been marked as a duplicate of this issue. ***