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

SegFault when superserver is restarted [CORE2865] #3249

Closed
firebird-automations opened this issue Feb 14, 2010 · 8 comments
Closed

SegFault when superserver is restarted [CORE2865] #3249

firebird-automations opened this issue Feb 14, 2010 · 8 comments

Comments

@firebird-automations
Copy link
Collaborator

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

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

resolution: Fixed [ 1 ]

Fix Version: 2.1.4 [ 10361 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

Edited the format of the description to make it flow better, less line breaks.

@firebird-automations
Copy link
Collaborator Author

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
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

=>

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

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

QA Status: No test => Cannot be tested

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

No branches or pull requests

2 participants