Issue Details (XML | Word | Printable)

Key: CORE-2865
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Alexander Peshkov
Votes: 0
Watchers: 0

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

SegFault when superserver is restarted

Created: 14/Feb/10 03:31 PM   Updated: 24/May/16 11:43 AM
Component/s: None
Affects Version/s: 2.1.3
Fix Version/s: 2.1.4

Environment: linux/sparc64

QA Status: Cannot be tested

 Description  « Hide
This bug was reported by PawelS <> 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 (
    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

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 14/Feb/10 03:47 PM
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

Sean Leyne added a comment - 15/Feb/10 09:20 PM
Edited the format of the description to make it flow better, less line breaks.