[lldb-dev] crashed vs. stopped process state
andrew.kaylor at intel.com
Thu Dec 13 12:26:30 PST 2012
Should I add something to bugzilla to track this?
From: Greg Clayton [mailto:gclayton at apple.com]
Sent: Thursday, December 13, 2012 12:13 PM
To: Kaylor, Andrew
Cc: lldb-dev at cs.uiuc.edu
Subject: Re: [lldb-dev] crashed vs. stopped process state
After speaking with Jim Ingham, we came up with:
- eStateCrashed should be removed all together, anywhere that was using this should be changed to eStateStopped
- The thread stop info is where the info should be contained for crashes
- In the future, we should add a StopClass enumeration that has accessors on the thread stop info class where the enum is something like:
eStopClassNormal, // Normal expected stop (used for breakpoints, watchpoints, etc)
eStopClassCrash, // Program will likely crash if there are no handlers installed
eStopClassFatalCrash // This will always crash the program };
On Dec 13, 2012, at 11:29 AM, Greg Clayton <gclayton at apple.com> wrote:
> On Dec 13, 2012, at 11:22 AM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote:
>> There are a couple of tests that are failing on Linux because the test is intentionally crashing the inferior process and expecting the process state to be eStateStopped, whereas on Linux the actual process state in these situations is eStateCrashed. I understand that on Darwin the state is eStateStopped in these cases, though I don't know why.
>> Can anyone shed some light on this for me?
> eStateCrashed means a non-recoverable stop state where the process can't continue and must be terminated. If we know the test is causing a crash state, then we should inforce this and fix the Mac side to comply and return the correct state.
> I would be interested to know what these cases are where the Mac is not returning the crashed state.
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
More information about the lldb-dev