Committed as r170224. -----Original Message----- From: Greg Clayton [mailto:[email protected]] Sent: Friday, December 14, 2012 10:22 AM To: Kaylor, Andrew Cc: Jim Ingham; [email protected] Subject: Re: [lldb-dev] crashed vs. stopped process state
Looks good. On Dec 14, 2012, at 10:13 AM, "Kaylor, Andrew" <[email protected]> wrote: > 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:[email protected]] > Sent: Thursday, December 13, 2012 1:33 PM > To: Kaylor, Andrew > Cc: Greg Clayton; [email protected] > 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" <[email protected]> > wrote: > >> Sounds reasonable. >> >> Should I add something to bugzilla to track this? >> >> -Andy >> >> -----Original Message----- >> From: Greg Clayton [mailto:[email protected]] >> Sent: Thursday, December 13, 2012 12:13 PM >> To: Kaylor, Andrew >> Cc: [email protected] >> 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 <[email protected]> wrote: >> >>> >>> On Dec 13, 2012, at 11:22 AM, "Kaylor, Andrew" <[email protected]> >>> 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 >>>> [email protected] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >>> >>> _______________________________________________ >>> lldb-dev mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > <process-state-stopped.patch> _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
