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
Server crashes during database shutdown [CORE4045] #4375
Comments
Modified by: @dyemanovassignee: Dmitry Yemanov [ dimitr ] |
Modified by: @dyemanovstatus: Open [ 1 ] => In Progress [ 3 ] |
Modified by: @dyemanovreporter: Dmitry Yemanov [ dimitr ] => Poul Dige [ tabulex ] |
Modified by: @dyemanovstatus: In Progress [ 3 ] => Open [ 1 ] |
Modified by: @dyemanovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 3.0 Alpha 1 [ 10331 ] Fix Version: 2.5.3 [ 10461 ] |
Modified by: @dyemanovFix Version: 3.0 Alpha 1 [ 10331 ] => |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovstatus: Closed [ 6 ] => Closed [ 6 ] QA Status: No test => Cannot be tested Test Details: Note. |
Submitted by: Poul Dige (tabulex)
The problem appears when a parallel helper thread attempts to detach from a database after the shutdown thread has decided to release all the database locks.
Stack trace:
Jrd::GlobalRWLock::lockRead(Jrd::thread_db * tdbb=0x0000000002cc7450, short wait=1, const bool queueJump=true)
Jrd::Attachment::backupStateReadLock(Jrd::thread_db * tdbb=0x00000001402bf831, short wait=-8680)
CCH_fetch_lock(Jrd::thread_db * tdbb=0x00000000020282b0, Jrd::win * window=0x0000000002ccde18, unsigned short
lock_type=62688, short wait=-32096, char page_type='')
CCH_fetch(Jrd::thread_db * tdbb=0x000000000227b830, Jrd::win * window=0x0000000003fcfc10, unsigned short
lock_type=64528, char page_type='ю', short checksum=1, short latch_wait=1, const bool read_shadow=true)
IDX_delete_indices(Jrd::thread_db * tdbb=0x00000000032d0040, Jrd::jrd_rel * relation=0x000000000455f3a0,
Jrd::RelationPages * relPages=0x0000000003fcf710)
Jrd::jrd_rel::delPages(Jrd::thread_db * tdbb=0x000000000337ed18, long tran=1077321176, Jrd::RelationPages *
aPages=0x0000000000000000)
TRA_release_transaction(Jrd::thread_db * tdbb=0x00000000000003e7, Jrd::jrd_tra *
transaction=0x000000000337ed18, Jrd::TraceTransactionEnd * trace=0x0000000000000000)
purge_transactions(Jrd::thread_db * tdbb=0x0000000002cc7450, Jrd::Attachment * attachment=0x0000000002cc7450,
const bool force_flag=false, const unsigned long att_flags=18)
purge_attachment(Jrd::thread_db * tdbb=0x0000000003fcfc10, Jrd::Attachment * attachment=0x0000000002cc7450,
const bool force_flag=false)
jrd8_detach_database(__int64 * user_status=0x0000000003fcfe10, Jrd::Attachment * * handle=0x000000000061e438)
fb_ping(__int64 * user_status=0x000000000061e438, unsigned int * db_handle=0x000000000061d550)
`anonymous namespace'::attachmentShutdownThread(void * arg=0x0000000000000004)
`anonymous namespace'::threadStart(void * arg=0x0000000000000000)
Commits: 71ceac0
====== Test Details ======
Note.
I remember that ~3-4 years ago I did test that made heavy workload on DB, then launched trace and finally - run "gfix -shut full".
After all activity finished, I scanned trace log for event like 'attach_database' which appeares in line *after* message 'connection shutdown'. Never found such case.
Though this idea may be interesting, I doubt that it relates to this ticket - correct pls if I'm wrong.
The text was updated successfully, but these errors were encountered: