crashed vs. stopped process state

Subprojects LLDB
#1

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?

Thanks,

Andy

#2

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

#3

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
};

#4

Sounds reasonable.

Should I add something to bugzilla to track this?

-Andy

#5

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

#6

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

process-state-stopped.patch (505 Bytes)

#7

Looks good.

#8

Committed as r170224.