Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fbclient access violation when handling fbserver shutdown [CORE1194] #1619

firebird-automations opened this issue Apr 5, 2007 · 6 comments


Copy link

Submitted by: Diane Downie (dianedownie)

Firebird 2.0 Superserver via IPC (using non-default names) to a local database actively via accessed over multiple threads from a single process.

I was testing recovery from when the firebird server is shutdown while my system was accessing it. I was able to consistently reproduce an access violation in fbclient while it was attempting to handle this situation. I did not try to repro this with 2.0.1, but will attempt to do so if you think the problem has been addressed.

Note that the service shutdown was not totally normal:
The Firebird Server - CSMInstance service is stopping.
A system error has occurred.
System error 1067 has occurred.
The process terminated unexpectedly.
The Firebird Server - CSMInstance service was stopped successfully.

My system that was executing database queries at the time of the shutdown generated generated this exception. It appears that fbclient detected the server had shutdown, but for some reason the address for the port 0x0 is being passed in and not handled. A full memory dump is available if requested.

First-chance exception at 0x014f0e33 (fbclient.dll) in rscorsvc.exe: 0xC0000005: Access violation reading location 0x00000008.
Thread 4800

> fbclient.dll!server_shutdown(rem_port * port=0x00000000) Line 1621 + 0xa bytes C++
fbclient.dll!xnet_read(xdr_t * xdrs=0x011ae488) Line 2042 C++
fbclient.dll!xnet_getbytes(xdr_t * xdrs=0x011ae598, char * buff=0x023ffbf4, unsigned int count=4) Line 1782 + 0x6 bytes C++
fbclient.dll!xnet_getlong(xdr_t * xdrs=0x011ae488, long * lp=0x023ffbf4) Line 1815 + 0x12 bytes C++
fbclient.dll!xdr_enum(xdr_t * xdrs=0x011ae488, xdr_op * ip=0x011adea0) Line 431 + 0xb bytes C++
fbclient.dll!xdr_protocol(xdr_t * xdrs=0x011ae488, packet * p=0x011adea0) Line 298 + 0x10 bytes C++
fbclient.dll!receive(rem_port * main_port=0x011ae40c, packet * packet=0x011adea0) Line 1546 + 0x13 bytes C++
fbclient.dll!rem_port::receive(packet * pckt=0x011adea0) Line 809 + 0x9 bytes C++
fbclient.dll!receive_packet_noqueue(rem_port * port=0x00000000, packet * packet=0x011adea0, long * user_status=0x00000000) Line 6107 + 0xa bytes C++
fbclient.dll!receive_packet(rem_port * port=0x00000000, packet * packet=0x011adea0, long * user_status=0x00000000) Line 6059 + 0xe bytes C++
fbclient.dll!receive_response(rdb * rdb=0x00000000, packet * packet=0x00000000) Line 6226 + 0x9 bytes C++
fbclient.dll!send_and_receive(rdb * rdb=0x00000000, packet * packet=0x00000000, long * user_status=0x023ffc4c) Line 6656 + 0x7 bytes C++
fbclient.dll!REM_allocate_statement(long * user_status=0x02485f2c, rdb * * db_handle=0x011ae5e4, rsr * * stmt_handle=0x023ffcfc) Line 1232 + 0x7 bytes C++
fbclient.dll!isc_dsql_allocate_statement(long * user_status=0x00000000, void * * db_handle=0x02096468, void * * public_stmt_handle=0x02485f28) Line 1990 + 0xc bytes C++
es_ext.dll!IibCursor::Open() Line 945 + 0x20 bytes C++
es_ext.dll!SACommand::Open() Line 3238 + 0xf bytes C++
es_ext.dll!SACommand::GetParamsSP() Line 3638 + 0xf bytes C++
es_ext.dll!SACommand::ParamCount() Line 3651 C++
es_ext.dll!FbDb::CheckParam(SACommand & cmd={...}, long lParam=2) Line 1743 + 0x8 bytes C++
es_ext.dll!FbDb::GetConfigValue(const wchar_t * szCategory=0x360e6390, const wchar_t * szName=0x360e6424, long * plValue=0x023ffefc) Line 2149 C++
es_ext.dll!ESThread::CheckFlexConfigurationInterval() Line 225 + 0x1d bytes C++
es_ext.dll!ESThread::OnInterval() Line 112 + 0x8 bytes C++
es_ext.dll!PerfThread::StartThread() Line 206 + 0xf bytes C++
es_ext.dll!StartPerf(void * lpVoid=0x02094238) Line 53 + 0x8 bytes C++
es_ext.dll!_callthreadstartex() Line 348 + 0xf bytes C
es_ext.dll!_threadstartex(void * ptd=0x020947c0) Line 331 C
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]

Commits: 33179d0 01232a2

Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

Copy link
Collaborator Author

Commented by: @dyemanov

The possible fix has been committed to CVS. I wasn't able to reproduce the (port == NULL) condition, but I've seen other crashes inside server_shutdown() related to the already freed xcc/xpm structures, and this fix solves all those issues. With some luck, we could expect your issue to be solved as well.

Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.0.4 [ 10211 ]

Fix Version: 2.1 Beta 2 [ 10190 ]

Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 11742 ] => Firebird [ 15534 ]

Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants