| Subject | Re: lock conversion denied/lock denied bug still exists in FB 2.5.3 |
|---|---|
| Author | |
| Post date | 2014-11-13T10:39:31Z |
No ths is not related to subject, this is another issue.
I have few such reports from customers but without test case to reproduce it.
I suspect this is related to garbage collection of a very long versions chain (ten's backversions for the same record).
gstat -r could confirm it.
Regards,
Vlad
---In firebird-support@yahoogroups.com, <abaddon@...> wrote :
I have few such reports from customers but without test case to reproduce it.
I suspect this is related to garbage collection of a very long versions chain (ten's backversions for the same record).
gstat -r could confirm it.
Regards,
Vlad
---In firebird-support@yahoogroups.com, <abaddon@...> wrote :
Also, possibly related to this (appears on same production servers) - sometimes all fb_inet_server.exe processes stop any disk i/o activity and wait for one process, which eats 100% of one CPU core.
Stack trace for hung thread look like this:
fb_inet_server!down_grade+0x145
fb_inet_server!down_grade+0x156
....tens of recursive down_grade calls
fb_inet_server!down_grade+0x156
fb_inet_server!blocking_ast_bdb+0x69
fb_inet_server!Jrd::LockManager::blocking_action+0x170
fb_inet_server!Jrd::LockManager::blocking_action_thread+0x11f
fb_inet_server!Jrd::LockManager::blocking_action_thread+0x9
fb_inet_server!`anonymous namespace'::threadStart+0x55
msvcr80!_endthreadex+0x3b
msvcr80!_endthreadex+0xc7
kernel32!BaseThreadInitThunk+0xe
ntdll_77770000!__RtlUserThreadStart+0x23
ntdll_77770000!_RtlUserThreadStart+0x1b
I has debug dump and lock print for hung process.