Summary: | exception from evaluateStatusVector (firebird/Util.cxx:53) after SQL error | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Terrence Enger <lo_bugs> |
Component: | Database | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | andrzej, iplaw67, mapopa |
Version: | 4.3.0.0.alpha0+ Master | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | typescript of gdb session |
Description
Terrence Enger
2013-12-27 15:54:01 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
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.