Download it now!
Bug 73073 - exception from evaluateStatusVector (firebird/Util.cxx:53) after SQL error
Summary: exception from evaluateStatusVector (firebird/Util.cxx:53) after SQL error
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.3.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Tamas Bunth
URL:
Whiteboard: target:5.3.0
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-27 15:54 UTC by Terrence Enger
Modified: 2016-09-10 15:19 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
typescript of gdb session (44.58 KB, text/plain)
2013-12-27 16:08 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Terrence Enger 2013-12-27 15:54:01 UTC
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.
Comment 1 Terrence Enger 2013-12-27 16:08:15 UTC
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
Comment 2 Terrence Enger 2013-12-27 16:15:51 UTC
Andrzej,

Do you want to take this one?

Terry.
Comment 3 Andrzej Hunt 2014-03-23 21:36:05 UTC
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...
Comment 4 Alex Thurgood 2015-01-03 17:40:49 UTC Comment hidden (no-value)
Comment 5 Terrence Enger 2015-08-08 02:01:11 UTC
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'
Comment 6 Tamas Bunth 2016-07-01 18:47:49 UTC
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.
Comment 7 Tamas Bunth 2016-07-02 13:08:54 UTC
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?
Comment 8 Lionel Elie Mamane 2016-07-03 17:20:12 UTC
(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.
Comment 9 Commit Notification 2016-08-17 13:16:49 UTC
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.
Comment 10 Terrence Enger 2016-09-10 15:19:03 UTC
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.