Issue Details (XML | Word | Printable)

Key: CORE-3767
Type: Bug Bug
Status: Open Open
Priority: Critical Critical
Assignee: Unassigned
Reporter: Petr Silar
Votes: 2
Watchers: 4

If you were logged in you would be able to see more operations.
Firebird Core

Embedded Firebird crashes inside of Jrd::LockManager::blocking_action_thread()

Created: 20/Feb/12 12:59 PM   Updated: 03/Apr/15 08:50 AM
Component/s: Engine
Affects Version/s: 2.5.0, 2.5.1
Fix Version/s: None

Environment: Windows

 Description  « Hide
We have several dumps of our application indicating crash inside of Firebird's embedded engine as follows (release

> .ecxr
eax=02a04924 ebx=76e31136 ecx=765b0ac4 edx=00000000 esi=ffffffff edi=02a04924
eip=039519c0 esp=08f4f7c4 ebp=00000001 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
039519c0 8b4808 mov ecx,dword ptr [eax+8] ds:002b:02a0492c=????????

ChildEBP RetAddr Args to Child
08f4f7c0 03951b06 00000001 0403491c 009ac044 fbembed!event_blocked [c:\..\firebird\src\jrd\isc_sync.cpp @ 717]
08f4f7d8 03a8d708 02a04924 00000001 00000000 fbembed!ISC_event_wait+0x66 [c:\..\firebird\src\jrd\isc_sync.cpp @ 1418]
08f4f848 03a8ded9 0392ed45 009ac044 3af780b6 fbembed!Jrd::LockManager::blocking_action_thread+0x178 [c:\..\firebird\src\lock\lock.cpp @ 1568]
08f4f84c 0392ed45 009ac044 3af780b6 00000000 fbembed!Jrd::LockManager::blocking_action_thread+0x9 [c:..\firebird\src\lock\lock_proto.h @ 403]
08f4f874 71fe29bb 009ad5e0 3afca5c2 00000000 fbembed!`anonymous namespace'::threadStart+0x55 [c:\..\firebird\src\jrd\threadstart.cpp @ 140]
WARNING: Stack unwind information not available. Following frames may be wrong.
08f4f8ac 71fe2a47 00000000 76e3339a 0a9b69f0 msvcr80+0x29bb
08f4f8c0 77c09ef2 0a9b69f0 76c1b716 00000000 msvcr80+0x2a47
08f4f900 77c09ec5 71fe29e1 0a9b69f0 00000000 ntdll!__RtlUserThreadStart+0x70
08f4f918 00000000 71fe29e1 0a9b69f0 00000000 ntdll!_RtlUserThreadStart+0x1b

Most of the crashes are from the moment when computer is waking up from hibernation.

[Guess:] It seems to me as insufficient fix of If I understand the code well, during LockManager's instance destruction, when the single turn of blocking_action_thread's loop takes too long, LockManager's destructor simply lefts the thread alone and frees itself which finally leads to access violation in the thread.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
There are no subversion log entries for this issue yet.