Steps to reproduce: (1) Run LibreOffice with command-line parameter --base to create (but do not register) /tmp/a1.odb with embedded firebird database. Program presents window "a1.odb". (2) Take menu options Tools > "SQL...". Program presents window "Execute SQL Statement". (3) Paste command create table t1 ( id integer not null, field1 varchar(20) not null ); into "Command to Execute" and click <Execute>. LO reports status: "1: Command executed successfully." (4) Paste command CREATE TRIGGER T1_BI FOR T1 ACTIVE BEFORE INSERT POSITION 0 AS BEGIN if (new.id IS null) THEN new.id = GEN_ID(GEN_T1ID, 1); END into "Command to execute" and click <Execute>. LO reports status: 2: firebird_sdbc error: *invalid request BLR at offset 23 *generator GEN_T1ID is not defined caused by 'isc_commit_transaction' This is entirely to be expected. (It was an accident the first time I did it.) (5) Close window "Execute SQL Statement". Program returns focus to window "a1.odb". (6) Take menu options File > Quit. Program presents prompt "Save Document?". (7) Click <Save>. Program fails with SIGABRT; the .odb is not updated. Note that the failure is somewhat fragile: (*) Not every SQL error in place of step (4) is followed by a crash. On the other hand, I have seen failures even when step (4) was followed by perfectly good SQL commands. (*) I am using a debug build. Unless the problem is seen in a non-debug build, I would presume that the debug build is part of the cause of the crash. These observations are from master commit b0926378, fetched 2013-12-06, configured as: --enable-option-checking=fatal --enable-dbgutil --enable-crashdump --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src built and executing on debian-wheezy: $ uname -a Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux $ java -version java version "1.6.0_27" OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1~deb7u1) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) $ gcc --version gcc (Debian 4.7.2-5) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Created attachment 91228 [details] typescript of gdb session At line 25 of the typescript, the program breaks on the throw statement, but this time the exception is caught. A couple of display statements and a backtrace follow. At line 259 of the typescript, the program breaks on the throw statement; this time the exception is not caught. A couple of display statements and a backtrace follow. At line 440 of the typescript, the program aborts. Backtrace follows. Note that the value 335544343, the value of aStatusVector[1], is manifest in firebird/src/include/gen/iberror.h as the value of constant isc_invalid_blr. I have observed one assignment (but not the assignment preceding the crash!) of this value to aStatusVector[1] with the top of the call stack looking like: #0 Jrd::LockManager::enqueue (this=<optimized out>, tdbb=0x7fffffff21a0, prior_request=<optimized out>, parent_request=<optimized out>, series=4, value=0x7fffffff0ac4 "\003", length=4, type=3 '\003', ast_routine=0, ast_argument=0x0, data=0, lck_wait=0, owner_offset=20904) at ../src/lock/lock.cpp:575 #1 0x00002aaad62519cf in enqueue (wait=0, level=3, lock=0x7fffffff0a50, tdbb=0x7fffffff21a0) at ../src/jrd/lck.cpp:909 #2 ENQUEUE (wait=0, level=3, lock=0x7fffffff0a50, tdbb=0x7fffffff21a0) at ../src/jrd/lck.cpp:144 #3 LCK_lock (tdbb=0x7fffffff21a0, lock=0x7fffffff0a50, level=3, wait=0) at ../src/jrd/lck.cpp:620 #4 0x00002aaad62b3a9b in TPC_snapshot_state (tdbb=0x7fffffff21a0, number=3) at ../src/jrd/tpc.cpp:254
Andrzej, Do you want to take this one? Terry.
Strange -- for some reason the error is only occuring when we try to commit the transaction, and not when executing the SQL to create the trigger. This then keeps repeating every time we try to commit the transaction, which also means we get this exception on saving the DB (and crash due to the function doing the saving not having sufficient exception specifications). I need to think carefully about this, safest option for now is probably to (if doing a DDL statement, which the trigger creation is) commit any existing transactions (to ensure we don't lose data), run the statement, commit (which is needed for any DDL statement and already happens), and if this post-DDL commit fails undo the transaction (haven't tested whether or not that's even possible yet -- it seems that the statement puts firebird into a slightly borked state so I have no confidence in that working). Not sure this is or isn't ultimately a firebird bug yet, I'm still debugging and experimenting...
Adding self to CC if not already on
The problem persists with daily dbgutil bibisect repository version 2015-08-07 ... Version: 5.1.0.0.alpha1+ Build ID: 09a9234c021ad98c5adeb493b5814e97b92ee912 Locale: en-CA (en_CA.UTF-8) which upon save-and-exit issues terminal messages ... warn:connectivity.firebird:6326:1:connectivity/source/drivers/firebird/Util.cxx:51: firebird_sdbc error: *invalid request BLR at offset 23 *generator GEN_T1ID is not defined caused by 'isc_commit_transaction' terminate called after throwing an instance of 'com::sun::star::sdbc::SQLException'
The bug still exists with version Firebird 3.0. I'm going to examine the issue and search for a solution, based on Andrzej's comment at first.
Please have a look at this patch: https://gerrit.libreoffice.org/26873/ With this, when the user executes a lot of DML statements and then executes a DDL statement unsuccessfully, then the data of the DML statements will be lost. Would that make sense to commit *before* every DDL statements to avoid this?
(In reply to Tamas Bunth from comment #7) > Please have a look at this patch: > https://gerrit.libreoffice.org/26873/ > > With this, when the user executes a lot of DML statements and then executes > a DDL statement unsuccessfully, then the data of the DML statements will be > lost. > Would that make sense to commit *before* every DDL statements to avoid this? Unless the user explicitly asks for a transaction, I think we should commit every change (DML statement) as soon as it succeeds, that's the GUI expectation. Many DBs have an "autocommit" mode that does that. If Firebird does, just enable it, else just wrap every statement (be it DDL or DDL) in a "SET TRANSACTION" / "COMMIT" block. I'd expect it will solve this bug. The documentation says Firebird supports nested transactions, so the user can still manually start a "wrapper" transaction that he/she commits whenever he/she wants.
Wastack committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d3a510e6ec7a42a7a30a24b7373931b8a8ef1a54 tdf#73073 GSoC Firebird Set autoCommit true It will be available in 5.3.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.
I see that the crash is gone in daily Linux dbgutil repository versions 2016-08-18 and 2016-09-09 running on debian-stretch. Thank you, Wastak. I am setting status VERIFIED FIXED.