Summary: | FILEOPEN: libreoffice base connection to mdb via odbc crashes on saving odb file | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | magowiz |
Component: | Base | Assignee: | Lionel Elie Mamane <lionel> |
Status: | RESOLVED NOTOURBUG | ||
Severity: | critical | CC: | chris, lionel, magowiz |
Priority: | low | ||
Version: | 4.1.2.3 release | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
See Also: | https://launchpad.net/bugs/1242355 | ||
Whiteboard: | BSA | ||
Crash report or crash signature: | Regression By: | ||
Attachments: |
odb file that points to mdb database
mdb file that causes the issue. |
Description
magowiz
2013-11-24 14:42:19 UTC
Could you please attach the .odb file that makes it crash? Created attachment 90103 [details]
odb file that points to mdb database
Created attachment 90104 [details]
mdb file that causes the issue.
(In reply to comment #1) > Could you please attach the .odb file that makes it crash? I attached both mdb and odb file since the odb points to real database : mdb file. Reproduced on two different machines: - libreoffice 4.1.3.2 (Debian package): infinite loop (memory consumption) - libreoffice 4.1 my own development tree: segfault in ODBC code Crash goes away (on Debian) after upgrading unixodbc to 2.3.1-1. So until hint to the contrary, seems to be a bug in UnixODBC -> NOTOURBUG. It does not work though, the list of tables is empty. This seems to be a mdbtools bug, because isql also cannot get the list of tables. Try: echo help | isql Pippo | less -SIM It "finds" 10 tables, but no info on them (no name, ...). The SQLTables function seems to be not implemented in mdbtools, or buggy on your particular example or ... (SQLGetData returns an error code, but subsequent SQLGetDiagRec returns all-zero SQLSTATE, no error string, ...). (In reply to comment #5) > Reproduced on two different machines: > - libreoffice 4.1.3.2 (Debian package): infinite loop (memory consumption) This was with mdbtools 0.7.1-1. This also is a mdbtools bug: calling SQLGetData on column 4 (TABLE_TYPE) of SQLTables returns SQL_NO_TOTAL in StrLen_or_IndPtr, indicating that there is more data to return, but the driver does not know how much. In this case, it returned all the data, namely "SYSTEM TABLE", so it should set StrLen_or_IndPtr to the length of that (that is, 12). Cf http://msdn.microsoft.com/en-us/library/ms715441%28v=vs.85%29.aspx Neither SQL_NO_TOTAL nor zero can be returned on the last valid call to retrieve data from a column, because the application would then have no way of knowing how much of the data in the application buffer is valid. |