Issue Details (XML | Word | Printable)

Key: CORE-4008
Type: Bug Bug
Status: Open Open
Priority: Blocker Blocker
Assignee: Unassigned
Reporter: Manoj Kumar
Votes: 0
Watchers: 2

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

fbclient hangs in xnet_putbytes while closing a connection or executing a transaction

Created: 10/Dec/12 09:52 PM   Updated: 03/Jan/13 05:18 PM
Component/s: None
Affects Version/s: 2.1.0, 2.1.1, 2.1.5
Fix Version/s: None

Environment: Windows Server 2008 R2

 Description  « Hide
This issue is coming in Firebird Superserver version on Windows Server 2008 R2 while closing a db connection or while executing a db query.

fbclient hangs in the thread (given below). We waited for 15 minutes before dumping.

DB Connection is local, on the same server. This issues is happening frequently, 3-4 times a day, sometimes frequency is higher.

First 12 frames are same for both call stack.

Closing Connection call stack:
ChildEBP RetAddr Args to Child
021be58c 76e20a91 00000304 00000000 021be5d4 ntdll!ZwWaitForSingleObject+0x15
021be5f8 75a81184 00000304 000001f4 00000000 KERNELBASE!WaitForSingleObjectEx+0x98
 021be610 75a81138 00000304 000001f4 00000000 kernel32!WaitForSingleObjectExImplementation+0x75
 021be624 10039d1e 00000304 000001f4 00a6d778 kernel32!WaitForSingleObject+0x12
021be648 10039434 00a6da98 021be66c 00a6d778 fbclient!xnet_putbytes+0x9e [...\src\remote\xnet.cpp @ 1897]
 021be658 10038265 00a6d80c 021be66c 10034ad4 fbclient!xnet_putlong+0x14 [...\src\remote\xnet.cpp @ 1968]
 021be664 10034ad4 00000043 00a6ddf0 015a7af8 fbclient!xdr_enum+0x55 [...\src\remote\xdr.cpp @ 429]
 021be688 10039b67 00a6d80c 00a6ddf0 00a6d778 fbclient!xdr_protocol+0x14 [...\src\remote\protocol.cpp @ 299]
 021be69c 10035bdb 00a6d778 00a6ddf0 1002b894 fbclient!send_full+0x17 [...\src\remote\xnet.cpp @ 1553]
 021be6a8 1002b894 00a6ddf0 00a6ddc8 1002c654 fbclient!rem_port::send+0xb [...\src\remote\remote.cpp @ 825]
 021be6b4 1002c654 00a6ddf0 00a62d68 00a6ddc8 fbclient!send_packet+0x74 [...\src\remote\interface.cpp @ 7247]
 021be6c8 1002e097 015a7af8 1a7b86b0 00a62d14 fbclient!send_and_receive+0x14 [...\src\remote\interface.cpp @ 7082]
 021be70c 1001cc64 015a7af8 00a62d24 00000002 fbclient!REM_free_statement+0x1d7 [...\src\remote\interface.cpp @ 2116]
 021be79c 70c7e232 015a7af8 015a7af4 00000002 fbclient!isc_dsql_free_statement+0x84 [...\src\jrd\why.cpp @ 3233]
 021be7b4 70c768ad 01599108 70c77518 00000000 xxxx!xxxx::Close+0x12

Executing a transaction call stack:
 # ChildEBP RetAddr
00 022ef520 76e20a91 ntdll!ZwWaitForSingleObject+0x15
01 022ef58c 75a81184 KERNELBASE!WaitForSingleObjectEx+0x98
02 022ef5a4 75a81138 kernel32!WaitForSingleObjectExImplementation+0x75
03 022ef5b8 10039d1e kernel32!WaitForSingleObject+0x12
04 022ef5dc 10039434 fbclient!xnet_putbytes+0x9e [...\src\remote\xnet.cpp @ 1897]
 05 022ef5ec 10038265 fbclient!xnet_putlong+0x14 [...\src\remote\xnet.cpp @ 1968]
 06 022ef5f8 10034ad4 fbclient!xdr_enum+0x55 [...\src\remote\xdr.cpp @ 429]
07 022ef61c 10039b67 fbclient!xdr_protocol+0x14 [...\src\remote\protocol.cpp @ 299]
 08 022ef630 10035bdb fbclient!send_full+0x17 [...\src\remote\xnet.cpp @ 1553]
09 022ef63c 1002b894 fbclient!rem_port::send+0xb [...\src\remote\remote.cpp @ 825]
 0a 022ef648 1002c654 fbclient!send_packet+0x74 [...\src\remote\interface.cpp @ 7247]
 0b 022ef65c 10030d38 fbclient!send_and_receive+0x14 [...\src\remote\interface.cpp @ 7082]
 0c 022ef69c 10021636 fbclient!REM_start_transaction+0xa8 [...\src\remote\interface.cpp @ 4457]
 0d 022ef798 100218f1 fbclient!isc_start_multiple+0xd6 [...\src\jrd\why.cpp @ 4997]
 0e 022ef8fc 70c7dde1 fbclient!isc_start_transaction+0xd1 [...\src\jrd\why.cpp @ 5076]

There was a similar issue reported in May, 2008 by Maxim Tkachuk:

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Manoj Kumar added a comment - 12/Dec/12 03:01 PM
Changing the Priority to Blocker. This bug is cauing frequent hangs in Production environment.

Dmitry Yemanov added a comment - 12/Dec/12 03:07 PM
If this is a blocker for you, why you still insist on using XNET for local connections instead of TCP localhost?

Manoj Kumar added a comment - 13/Dec/12 05:26 PM
I thought XNET protocol is more robust for local clients as per Release notes of 2.1.5
So are you suggesting, we should not use XNET at all for local connections. Please confirm.

More on the bug:
This problem is coming intermittently but coming more often on servers with constant load (Database load).

Vlad Khorsun added a comment - 14/Dec/12 09:58 AM
I can't reproduce case by Maxim Tkachuk. More, it was about FB 2.5, while this ticket is about 2.1.
I don't think we can help much without reproducible example.

> I thought XNET protocol is more robust for local clients as per Release notes of 2.1.5
More robust ???
More performance - could be. But i never compare robustness of protocol implementations...

Manoj Kumar added a comment - 03/Jan/13 05:18 PM
Hi Vlad,
This issue is consistent in our environment though not reproducbile. We have dump files if that can help. Thanks.