[lldb-dev] crashed vs. stopped process state

[Kaylor, Andrew]

Can you take a quick look at the attached patch?  This was the only place I saw where the state was being set to eStateCrashed.  There are lots of places still checking for that state, but I'm thinking we can clean that up later.

-Andy

-----Original Message-----
From: Jim Ingham [mailto:jingham at apple.com] 
Sent: Thursday, December 13, 2012 1:33 PM
To: Kaylor, Andrew
Cc: Greg Clayton; lldb-dev at cs.uiuc.edu
Subject: Re: [lldb-dev] crashed vs. stopped process state

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: process-state-stopped.patch
Type: application/octet-stream
Size: 505 bytes
Desc: process-state-stopped.patch
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20121214/bd4bc143/attachment.obj>