[lldb-dev] crashed vs. stopped process state

Jim Ingham jingham at apple.com
Thu Dec 13 13:33:09 PST 2012


Yes, that sounds good.  In the meantime, just have the Linux plugin always set the stopped state to eStateStopped, and you should be alright.

Jim

On Dec 13, 2012, at 12:26 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote:

> Sounds reasonable.
> 
> Should I add something to bugzilla to track this?
> 
> -Andy
> 
> -----Original Message-----
> 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:
> 
> enum StopClass
> {
>   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.
>> 
>> Greg
>> 
>> 
>>> Thanks,
>>> Andy
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>> 
>> 
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev




More information about the lldb-dev mailing list