Description: I am working with libreoffice and openoffice with sqlite3 odbc and I have noticed that to do a forms and within it to put a table control (grid) in libreoffice I am in the program room or it does not let me go to the registry that is not signaled and in openoffice yes . That's why I think it could be a bug, if it's not already communicated it would be new. I posted it in ask Libreoffice in English. Actual Results: I can send you the zip file (finca.odb + sqlite file) Expected Results: It takes me out of libreoffice base Reproducible: Always User Profile Reset: Yes Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Created attachment 138473 [details] finca.odb + finca_sqlite.sqlite
*** Bug 106998 has been marked as a duplicate of this bug. ***
Could you please add a more simple database? I hoped to understand the bugdescription by downloading the attached document - but with 17 forms and 16 modules for Basic-code and a connection to SQlite I can't get any hint to understand the description better.
So, if I understand this correctly, you are expecting LibreOffice to opent the Windows registry for some reason ? What reason might that be ? Which ODBC driver are you using ? How is the behaviour different with OpenOffice.org ? Please provide detailed steps as to how to reproduce this, as currently I have no idea of what you are attempting. Setting to NEEDINFO pending requested information. Please set back to unconfirmed once you have provided the detailed steps and setup.
Created attachment 138553 [details] ERROR IN THE 1st GROUP OF TABLES
In the forms of F2_compras, F2_pagos, F3_sales, F3_cobros in the first group of tables does not allow me to move through it as I do in openoffice and sometimes I get out of the program by just activating this form, in some cases it only allows me to be in the active record and when it happens to others it leaves the program. I use Sqlite odbc 3.15.2 + windows xp or windows 8 sp Say that the group of tables has a calculated field of a query + 3 fields listed to obtain data from other tables. I attached a drawing of F2_compras and the part that gives me problems.
my libreoffice is 5.4.4.2 Spanish I do not have the problem in the control table connected to sqlite 3 odbc thanks for everything
I opened the database with disabled macros. I could confirm a crash when starting the form F2_COMPRAS: crashreport.libreoffice.org/stats/crash_details/0f63ba8a-525a-41c9-85d4-d9cd8d33dbfe Sometimes the form will be opened when starting LO again, But there isn't any content shown in the form. This crash happens with LO Version: 5.4.4.2 under OpenSUSE 42.2 64bit rpm Linux. I got the same crash with Apache OpenOffice 4.1.3 Please show the content of your odbc.ini odbcinst.ini Write down also the OpenOffice-version, which with you could connect to the database through ODBC and could open the form. You had assigned yourself for solving this bug - think this is an error and have put it back to default.
Have tested a little bit more. Last installed version, which opens the form F2_COMPRAS without a crash and where it is possible to see data is LO 5.4.0.3 on OpenSUSE 42.2 64bit rpm Linux. First version, which I have installed and which fails is LO 5.4.3.2 So I set this bug to NEW and Keyword "regression". Content of odbcinst.ini here: [SQLITE3] Description=SQLite ODBC 3.X Driver=/usr/lib64/libsqlite3odbc.so Setup=/usr/lib64/libsqlite3odbc.so Threading=2 FileUsage=1 UsageCount=1 Content of odbc.ini [FINCA_SQLITE] Description= FINCA Bug Driver= SQLITE3 Database= /home/<username>/Downloads/FINCA/FINCA_SQLITE.sqlite
Created attachment 138763 [details] Error in Libreoffice 5.4.4.2 I send you an image of the error that I have
You could try to install LO 5.3.7.2 instead. Works here with the form without crash. Let's hope it will be bibisected.
Have set Hardware back to ALL. See comment 8 and comment 9. Isn't specific to Windows. Appears also under Linux 64bit.
Regression introduced by: author Julien Nabet <serval2412@yahoo.fr> 2017-10-07 22:58:34 +0200 committer Julien Nabet <serval2412@yahoo.fr> 2017-10-08 07:47:21 +0200 commit 12d5e57dcac22c288ef23075b82e3e3e87929912 (patch) tree 40320ef42a368ab5735d99309483ca52f9d895b7 parent 4d94541a7b88b76d856e30dba7f8a3de48260eda (diff) tdf#112947: fix write to free'd memory (odbc) Bisected with: bibisect-linux64-6.0 Adding Cc: to Julien Nabet
On pc Debian x86-64 with master sources updated some days ago, I fail to install odbc env. Here what I did: - installed unixodbc - installed libsqliteodbc /etc/odbcinst.ini contains: [SQLITE] Description=SQLite ODBC Driver Driver=libsqliteodbc.so Setup=libsqliteodbc.so Threading=2 FileUsage=1 UsageCount=1 [SQLITE3] Description=SQLite3 ODBC Driver Driver=libsqlite3odbc.so Setup=libsqlite3odbc.so Threading=2 FileUsage=1 UsageCount=1 I can create a brand new odb and open tables of the sqllite file, so it's not a pb of drivers. In ~/.odbc.ini, I got: [bug_114495] Description= FINCA Bug Driver= SQLITE3 Database= /home/julien/lo/bugs/114495_odbcreg/FINCA_SQLITE.sqlite Here's the error: The connection to the data source "FINCA_SQLITE" could not be established SQL Status: IM002 [unixODBC][Driver Manager]Data source name not found, and no default driver specified
Ok I found it: I must put in ~/.odbc.ini [FINCA_SQLITE] Description= FINCA Bug Driver= SQLITE3 Database= /home/julien/lo/bugs/114495_odbcreg/FINCA_SQLITE.sqlite
Created attachment 138913 [details] bt with debug symbols
Created attachment 138915 [details] some bts I put a trace when connections were created and released. I noticed one which was cleared but was used afterwards. So I put in the tar.bz2, the 3: - connection creating - connection disposing - wrong connection using It's indeed a regression but I think too that the patch I had pushed revealed an existing bug. Of course, it must be fixed ASAP.
Lionel: thought you may be interested be interesting in this one. Meanwhile, I'll keep on digging on this one too.
I submitted a patch to review on gerrit here: https://gerrit.libreoffice.org/#/c/47496/
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=89e354eff9d99d05461e2892fb1af56d186b8653 tdf#114495: fix crash in odbc resultset dtr It will be available in 6.1.0. 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 "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9dfd1f62ab0cf22d1f8550f64d03bcd3b94669c0 Revert "tdf#114495: fix crash in odbc resultset dtr" It will be available in 6.1.0. 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.
*** Bug 114850 has been marked as a duplicate of this bug. ***
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=964cc98794941dbf7dccce526c4fa88c16b3a26c tdf#114495 ODBC: clear row status buffer *before* we throw away the statement It will be available in 6.1.0. 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-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1572c3bde7fd30fc2e019ec3d7c6c629343b18e9&h=libreoffice-6-0 tdf#114495 ODBC: clear row status buffer *before* we throw away the statement It will be available in 6.0.0.2. 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.
Verified in Version: 6.1.0.0.alpha0+ Build ID: 0ef0740298b45379bbf8d00d50beffee7a2f812a CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded Thanks Julien for fixing this issue!
*** Bug 114089 has been marked as a duplicate of this bug. ***
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1cb3e8f328dafffbe2449043894526f8d79405fb&h=libreoffice-5-4 tdf#114495 ODBC: clear row status buffer *before* we throw away the statement It will be available in 5.4.5. 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.
I have installed the libreoffice 6.0.0.2 and it is appreciated that the error is fixed windows 8.1 sqlite odbc
*** Bug 115289 has been marked as a duplicate of this bug. ***