Created attachment 75141 [details] Sample ODBC database (SQLite) and BASE document When connecting to an ODBC database, a memo field with greater than 1023 bytes of text causes extremely slow performance and displays garbage at the end of the field. It is strongly suspected there is an overflow of a 1k buffer. Attached is a sample SQLite database illustrating the problem, and a "Base" database that connects to it. To reproduce the problem with my sample file... REQUIRED: - SQLite ODBC driver. You need the 32-bit driver even on a x64 system in Windows since there is no 64 bit LibreOffice build for Windows. You can download this at http://www.ch-werner.de/sqliteodbc/ Steps: 1) Set up the ODBC DSN for the sample database. Use the normal ODBC administrator through your control panel for 32-bit Windows. For 64-bit Windows, you must create the ODBC datasource using "c:\windows\sysWOW64\odbcad32.exe" to access the 32-bit ODBC system. In either case, create a datasource named "ODBCTEST1" and point it to the "ODBCTest.db" sample in the zip file attached to this report. 2) Open the sample "Base" database ODBCTest.odb. Select tables and open the "Test1" table. 3) The Memorandum field in row 1 has 1023 bytes. In row 2 it has 1024 bytes. If you click on that field in row 1 and hit the "END" button on your keyboard, you will notice it displays properly. If you click on that column in row 2 and hit "END", you will notice a bunch of junk oriental characters. Scrolling through that field is extremely slow. Any handling of rows with such fields is very slow. 4) If you copy (CRTL-C) an affected field, then paste it into another program, the text pastes correctly. If you try and display it in any way within "Base" (table, queries, forms), all the junk characters are added and performance degrades. This same ODBC database works in 32 and 64 bit versions of Windows with the same ODBC driver using 3.5 versions of LibreOffice. It is unknown what interim version introduced this bug.
Created attachment 75181 [details] typescript: under valgrind on linux, ending with segfault For what little it is worth, I see no problem with master commit 2e367c0, pulled 2013-02-17, built and running on ubuntu-natty (11.04) 32-bit, with sqlite3 version 3.7.4-2ubuntu5. Execution under valgrind, however, caused a segfault.
(In reply to comment #1) > For what little it is worth, I see no problem with master commit > 2e367c0, pulled 2013-02-17, built and running on ubuntu-natty (11.04) > 32-bit, with sqlite3 version 3.7.4-2ubuntu5. I'm not certain the problem manifests in Linux. It's possible, if not likely, that a buffer overflow would have different symptoms in Linux anyway. I've tried release 3.6.5.2 and the problem does not manifest. So far the 4.0.0.3 release, and daily builds for today of 4.0.2 and master both do manifest the problem. I do not know if any early 4.0 pre-releases exhibit the problem.
Having tried to dig into my segfault, I now think that it is nothing to do with this bug. Sorry for the noise.
Lionel - this one seems vaguely familiar, do you have a few minutes to take a look at it and confirm it?
The buffer is 2048 bytes, but that corresponds to 1024 UTF-16 code units (including terminating NULL -> 1023 "real" code units), so this is plausible. With my testing under GNU/Linux, the SQLite ODBC driver reports SQL_CHAR type for the column (8-bit text encoding). Probably the Windows version reports SQL_WCHAR (16-bit text encoding)...
Sorry, I was mistaken. The buffer is actually 2048 *characters*, so in the WCHAR case, it is 4096 bytes. So the "1024 characters" limit makes no sense to me, unless there is some mixup between SQL_CHAR and SQL_WCHAR... Ah, found it! I mixed up length (number of UTF16 code units) and size (number of bytes) again...
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a63c9bac6a6223ac716b7bcb590dac4eb01d5def fdo#61142 mixup between size and length 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.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b475a63edea91daccfc179506b53a5f2ae7fc12b&h=libreoffice-4-0 fdo#61142 mixup between size and length It will be available in LibreOffice 4.0.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.