Bug 73073 - exception from evaluateStatusVector (firebird/Util.cxx:53) after SQL error
Summary: exception from evaluateStatusVector (firebird/Util.cxx:53) after SQL error
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Database (show other bugs)
Version: 4.3.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-27 15:54 UTC by Terrence Enger
Modified: 2015-01-03 17:40 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


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

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
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.