[SERVER-38819] record stack trace in handler for WT_PANIC Created: 03/Jan/19  Updated: 27/Oct/23  Resolved: 07/Jan/19

Status: Closed
Project: Core Server
Component/s: WiredTiger
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Eric Milkie Assignee: Eric Milkie
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to WT-4518 Give applications a chance to handle ... Closed
Participants:

 Description   

Currently, we simply call fassert() in mdb_handle_error(). This eventually calls std::abort(), and lets our signal handler record a stack trace.
Unfortunately, because WiredTiger sets a panic flag on the WT connection, this causes all other threads that happen to call into WiredTiger to immediately return WT_PANIC. These threads will race with the panicking thread for the signal handler. Depending on who wins the race, we can sometimes record a stack trace that isn't useful.

The proposal here is to manually record a stack trace in mdb_handle_error() before calling fassert, thus guaranteeing we get at least one stack trace that shows the actual point of panic.



 Comments   
Comment by Eric Milkie [ 07/Jan/19 ]

WT-4518's completion renders this ticket extraneous.

Comment by Keith Bostic (Inactive) [ 07/Jan/19 ]

milkie, we pushed WT-4518, back to you.

Comment by Eric Milkie [ 03/Jan/19 ]

Yes, that should be part of the work for this ticket.

Comment by Andy Schwerin [ 03/Jan/19 ]

If we do this, should we switch to fassertFailedNoTrace since the relevant stack trace will already have been logged?

Comment by Eric Milkie [ 03/Jan/19 ]

Note that this ticket won't be necessary if we do WT-4518 instead.

Generated at Thu Feb 08 04:50:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.