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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.