Description: opening an old database (via sqlite-Backend) crashes immediately when opening tables or views, I already tried to switch installed java version to no avail, opening the databasse with an windows LO 5.8.1 works without any problems. Steps to Reproduce: 1. Open data base 2. Open view or tables 3. Actual Results: LO crashes and offers to restore database Expected Results: Database should open as it does when opened from Windows version Reproducible: Always User Profile Reset: Yes Additional Info: Version: 25.8.1.1 (X86_64) Build ID: 54047653041915e595ad4e45cccea684809c77b5 CPU threads: 2; OS: Linux 6.16; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded nvidia driver all 550.163.01-3
Can you provide an example database for testing? When was the last time this worked on Linux for you? Note for testers: https://wiki.documentfoundation.org/Documentation/HowTo/Base/Connect_to_SQLite What kind of a setup did you use for connecting?
Created attachment 202918 [details] sample database that uses sqlite3
Created attachment 202919 [details] /etc/odbc.ini this is the file that installs the user odbc access
this is an sample database that crashes also base, with a ODBC sqlite3 database (not provided, any sqlite3 database will do)
The last time it worked for me was I believe in August, when I used 25.8.0.4, or even before when using 25.2.5.2 (before August 22th) , and nvidia was 550.163.01-2 or before 2025-07-24 it was 550.163.01-1
or, if unixodbc is culprit, before 2025-09-04 i used 2.3.12-2, and then 2.3.12-2+b1, and August 20 libsqliteodbc changed from 0.99991-2 to 0.99991-2+b1 and on September 09 to 0.99991-3
(In reply to Heinz Repp from comment #2) > Created attachment 202918 [details] > sample database that uses sqlite3 Where is the sqlite file that this is supposed to connect to ? All you have provided with the ODB file is the indication of how the connection is supposed to happen, i.e. over ODBC, but the ODB file doesn't contain the sqlite3 db (it isn't embedded). It also doesn't specify which ODBC driver version you are using. =>> NEEDINFO
For example, your ODBC.ini file points to: Database = /home/h1/Dokumente/Daten/Fx-downloadhistory.sqlite We need that file to test whether: (1) a connection can be established via ODBC with an appropriate driver, yet to be named ; (2) a connection can be established using some other driver, e.g. JDBC, direct SQLite driver (SDBC), etc
Created attachment 202933 [details] this is the file that should be opened
Created attachment 202934 [details] and this is the file defining the possible sources
the odbc version that I use is 2.3.12-2+b1, the current version in debian testing.
For the sake of comparison, no crash for me with a direct SQLite driver, but the data of the table "moz_downloads" does not display and throws error message: "SQLite only supports TYPE_FORWARD_ONLY cursors" This is a known limitation of LO. Even setting the advanced parameter of "Respect the result set type of the database driver" only removes the error message, but does not display any table data Version: 25.8.1.1 (AARCH64) Build ID: 54047653041915e595ad4e45cccea684809c77b5 CPU threads: 8; OS: macOS 26.0.1; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
No crash either with Xerial JDBC driver 3.50.0.0.jar and Version: 25.8.1.1 (AARCH64) Build ID: 54047653041915e595ad4e45cccea684809c77b5 CPU threads: 8; OS: macOS 26.0.1; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded The only issue I see here is the incorrect display of timestamp fields in engineering notation, which might correspond to bug 153678, but that is a different issue to the one originally reported here.
Heinz: you could use the debuginfod service probably supported by your distro to take a backtrace of the hang: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace With debuginfod, the debug information is fetched over the network on demand and there is no need to worry about installing any extra packages. When the debugger starts, it will ask you, if you agree to use the service.
Created attachment 203482 [details] gbdtrace.log when opening fx-downloads.odb this is the crash opening fx-downloads.odb
Created attachment 203483 [details] this is when opening a productive database this crash appears immediately when I open a productive database, and chose "tables"
Hmm, looks like the debug info was still missing in those traces.
Hmm, if debug info is missing in those traces, then please advise me how to include it. I followed the instructions in https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace .
(In reply to Heinz Repp from comment #18) > Hmm, if debug info is missing in those traces, then please advise me how to > include it. I followed the instructions in > https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU. > 2FLinux:_How_to_get_a_backtrace . Which Linux distro are you using? Did GDB ask you to use debuginfod when you launched it and you answered yes?
I use debian testing fully updated, gdb is GNU gdb (Debian 16.3-5), and after soffice --backtrace there was no gdb message I could have reacted to.
(In reply to Heinz Repp from comment #20) > I use debian testing fully updated, gdb is GNU gdb (Debian 16.3-5), and > after soffice --backtrace there was no gdb message I could have reacted to. Ok, sorry about that. It might be that you need to install the libdebuginfod package: https://wiki.debian.org/Debuginfod Another, longer, way to initiate the backtrace process is by launching LibreOffice first and then in a terminal running: gdb --pid=$(pidof soffice.bin) At this point it should ask to enable debuginfod. Then in gdb: set logging enabled on and continue (or just c) and then in LibreOffice, open the database to make it crash. With the crash, gdb shows the prompt and you can say backtrace (or just bt) Now a gdb.txt file should be found in the directory where you invoked gdb. Finally, you can say quit in gdb.
Tested with Version: 25.8.2.2 (X86_64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded on OpenSUSE 15.6 with UnixODBC. Couldn't reproduce any crash here.
That's pretty crasy. After installing libdebuginfod and trying again, I could open all databases without any crash, and work with it. After /opt/libreoffice25.8/program/soffice --backtrace gdb tells me Reading symbols from /opt/libreoffice25.8/program/soffice.bin... (No debugging symbols found in /opt/libreoffice25.8/program/soffice.bin) log will be saved as gdbtrace.log, this will take some time, patience... and gdbtrace.log starts with: warning: Currently logging to gdbtrace.log. Turn the logging off and on to make the new setting effective. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". and it ends with [New process 5666] [Inferior 1 (process 5666) exited normally] /opt/libreoffice25.8/program/gdbtrace:9: Error in sourced command file: No stack. and all ends normal.
and using LibreOffice Base from the menu works also flawlessly.
Only things that changed in between: libsqliteodbc changed from 0.99991-3 to 0.99991-5 on 2025-10-26 12:07 and I installed the new aqbanking-libs (6.7.7beta-1) on 2025-10-27 10:33.
*** Bug 169065 has been marked as a duplicate of this bug. ***