SegFault when superserver is restarted [CORE2865] #3249
Comments
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
|
Commented by: @AlexPeshkoff Old strategy (THREAD_ENTER and never THREAD_EXIT) when shutdown appeared not efficient - database service threads like GC can't finish without rescheduling. Therefore ideas of shutdown (but not implementation) are partially taken from 2.5 - do not let worker threads enter yValve after shutdown started |
Modified by: @AlexPeshkoffstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.1.4 [ 10361 ] |
|
Commented by: Sean Leyne (seanleyne) Edited the format of the description to make it flow better, less line breaks. |
Modified by: Sean Leyne (seanleyne)description: This bug was reported by PawelS <mailto:pawel.sawicki@motorola.com> in fbdevel. We run Firebird (2.1.3) on SPARC machine and from time to time (few times a #0 0x00000001000f1768 in Firebird::MemoryPool::blk_type ( => This bug was reported by PawelS <mailto:pawel.sawicki@motorola.com> in fbdevel. We run Firebird (2.1.3) on SPARC machine and from time to time (few times a day) we observe core dump, which occurs when server is restarted. I collected many such events and in all cases debugger reports that segmentation fault took place during 'process_packet' routine. #0 0x00000001000f1768 in Firebird::MemoryPool::blk_type ( |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovQA Status: No test |
Modified by: @pavel-zotovstatus: Closed [ 6 ] => Closed [ 6 ] QA Status: No test => Cannot be tested |
Submitted by: @AlexPeshkoff
This bug was reported by PawelS <mailto:pawel.sawicki@motorola.com> in fbdevel.
We run Firebird (2.1.3) on SPARC machine and from time to time (few times a day) we observe core dump, which occurs when server is restarted. I collected many such events and in all cases debugger reports that segmentation fault took place during 'process_packet' routine.
At the same time 'shutdown_thread' tries to close SecurityDatabase. Perhapes I am missing something but I think that when shutown_thread is activated all other threads should be suspended and stop serving requests from clients beacuse some important data may have been already deleted at that point.
This is emphasized in comment after line 6634 in file jrd.cpp. Occasionally after such crash we get corrupted database. An example debugger report is attached below
#0 0x00000001000f1768 in Firebird::MemoryPool::blk_type (
mem=0xffffffff769063e0)
at ../src/jrd/../jrd/../jrd/../common/classes/alloc.h:375
#1 0x0000000100294640 in jrd8_release_request (
user_status=0xffffffff7affb3a8, req_handle=0xffffffff7e104350)
at ../src/jrd/jrd.cpp:3258
#2 0x0000000100115668 in isc_release_request (user_status=0xffffffff7affb3a8,
req_handle=0xffffffff7440de18) at ../src/jrd/why.cpp:4366
#3 0x000000010039bb00 in release_request (request=0xffffffff7440dd68,
top_level=true) at ../src/dsql/dsql.cpp:5037
#4 0x000000010039bbe4 in GDS_DSQL_FREE_CPP (user_status=0xffffffff7affb8f0,
req_handle=0xffffffff7e104428, option=2) at ../src/dsql/dsql.cpp:1185
#5 0x000000010039bdcc in dsql8_free_statement (
user_status=0xffffffff7affb8f0, req_handle=0xffffffff7e104428, option=2)
at ../src/dsql/dsql.cpp:334
#6 0x000000010011d238 in isc_dsql_free_statement (
user_status=0xffffffff7affb8f0, stmt_handle=0xffffffff7e104398, option=2)
at ../src/jrd/why.cpp:3231
#7 0x00000001000dfdfc in rem_port::end_statement (this=0xffffffff7cd09478,
free_stmt=0xffffffff7cd0f798, sendL=0xffffffff7cd0ef78)
at ../src/remote/server.cpp:1862
#8 0x00000001000e1cb8 in process_packet2 (port=0xffffffff7cd09478,
sendL=0xffffffff7cd0ef78, receive=0xffffffff7cd0f3d0,
result=0xffffffff7affbd48) at ../src/remote/server.cpp:3633
#9 0x00000001000e1fb0 in process_packet (port=0xffffffff7cd09478,
sendL=0xffffffff7cd0ef78, receive=0xffffffff7cd0f3d0,
result=0xffffffff7affbd48) at ../src/remote/server.cpp:3371
#10 0x00000001000e2ee0 in loopThread (flags=0x2)
at ../src/remote/server.cpp:5392
#11 0x000000010010b538 in (anonymous namespace)::ThreadArgs::run (
this=0xffffffff7affbf28) at ../src/jrd/ThreadData.cpp:274
#12 0x000000010010b198 in (anonymous namespace)::threadStart (
arg=0xffffffff7e109c50) at ../src/jrd/ThreadData.cpp:284
Commits: 8af7b77
The text was updated successfully, but these errors were encountered: