Subject | Re: Server 2.1.1 hang |
---|---|
Author | rtbunker |
Post date | 2008-11-12T00:22:22Z |
--- In firebird-support@yahoogroups.com, Dmitry Yemanov <dimitr@...>
wrote:
by just grabbing stacks in Visual Studio. If there's a firebird tool
to dump these or a better format, let me know, i'm not too familiar
with the tracing facilities in firebird.
Thread 1
----------
Firebird::BePlusTree::getPrev(),
Firebird::MemoryPool::internal_alloc() Line 1317 C++
Firebird::MemoryPool::allocate_nothrow() Line 721 + 0x25 bytes C++
Firebird::AbstractString::reserveBuffer() Line 102 C++
Firebird::AbstractString::baseAssign() Line 128 C++
Firebird::AbstractString::vprintf() Line 403 + 0x16 bytes C++
Firebird::AbstractString::printf(...) Line 358 C++
CNTL_init() Line 82 + 0x13 bytes C++
WinMain() Line 295 C++
__tmainCRTStartup() Line 578 + 0x1d bytes
Thread 2
----------
CCH_release()
CCH_handoff() Line 1624 + 0xd bytes C++
BTR_find_page() Line 889 + 0x12 bytes C++
BTR_evaluate() Line 797 C++
pass1() Line 3866 + 0x1f bytes C+
Thread 3
----------
Firebird::MemoryPool::MemoryPool() Line 300 + 0x8c bytes C++
Firebird::MemoryPool::internal_create() Line 1075 + 0xf bytes C++
7c901046 <-- jrd8_ddl shows a call into DYN_ddl, that must end
up here?
jrd8_ddl() Line 2217 C++
isc_ddl() Line 1872 + 0x25 bytes C++
DDL_execute() Line 298 + 0x1c bytes C++
execute_request() Line 3345 + 0x6 bytes C
The MemoryPool calls in Thread 3 are suspect to me as this would
appear to be hanging in InitializeCriticalSection, which seems
unlikely.
Sometimes there are two calls into BePlusTree::getPrev on the stack.
I wonder if that's where the culprit lies? Deadlock in multi-threaded
BePlusTree access?
I consistently get 3 threads in some combination of freeBlock access,
CCH_release, and jrd8_ddl. I'll continue repro'ing and see if i get
any more helpful stacks.
:)ross
wrote:
>Here's an example of stacks that are not in stall. I generated these
> Could you please show us the complete stack trace?
>
>
> Dmitry
>
by just grabbing stacks in Visual Studio. If there's a firebird tool
to dump these or a better format, let me know, i'm not too familiar
with the tracing facilities in firebird.
Thread 1
----------
Firebird::BePlusTree::getPrev(),
Firebird::MemoryPool::internal_alloc() Line 1317 C++
Firebird::MemoryPool::allocate_nothrow() Line 721 + 0x25 bytes C++
Firebird::AbstractString::reserveBuffer() Line 102 C++
Firebird::AbstractString::baseAssign() Line 128 C++
Firebird::AbstractString::vprintf() Line 403 + 0x16 bytes C++
Firebird::AbstractString::printf(...) Line 358 C++
CNTL_init() Line 82 + 0x13 bytes C++
WinMain() Line 295 C++
__tmainCRTStartup() Line 578 + 0x1d bytes
Thread 2
----------
CCH_release()
CCH_handoff() Line 1624 + 0xd bytes C++
BTR_find_page() Line 889 + 0x12 bytes C++
BTR_evaluate() Line 797 C++
pass1() Line 3866 + 0x1f bytes C+
Thread 3
----------
Firebird::MemoryPool::MemoryPool() Line 300 + 0x8c bytes C++
Firebird::MemoryPool::internal_create() Line 1075 + 0xf bytes C++
7c901046 <-- jrd8_ddl shows a call into DYN_ddl, that must end
up here?
jrd8_ddl() Line 2217 C++
isc_ddl() Line 1872 + 0x25 bytes C++
DDL_execute() Line 298 + 0x1c bytes C++
execute_request() Line 3345 + 0x6 bytes C
The MemoryPool calls in Thread 3 are suspect to me as this would
appear to be hanging in InitializeCriticalSection, which seems
unlikely.
Sometimes there are two calls into BePlusTree::getPrev on the stack.
I wonder if that's where the culprit lies? Deadlock in multi-threaded
BePlusTree access?
I consistently get 3 threads in some combination of freeBlock access,
CCH_release, and jrd8_ddl. I'll continue repro'ing and see if i get
any more helpful stacks.
:)ross