[Lldb-commits] [lldb] r180829 - Make "process handle -n true -s false" actually notifies of the signal.
Malea, Daniel
daniel.malea at intel.com
Thu May 2 15:00:51 PDT 2013
Thanks for the information about Resumes; I did not know about these 3
types! I will need to look at this further tomorrow and figure out what it
is that triggers this resume that hangs.
Cheers,
Dan
On 2013-05-02 5:53 PM, "jingham at apple.com" <jingham at apple.com> wrote:
>
>On May 2, 2013, at 2:06 PM, "Malea, Daniel" <daniel.malea at intel.com>
>wrote:
>
>> Right; what's happening is the call to WaitForNextStateChangeEvent (on
>> line 1240) never returns. After reading the other thread with Carlo,
>>it's
>> evident my fix is not correct, so I reverted it.
>>
>> The GetRestartedFromEvent code I think is OK, as I'm able to see other
>> Stop events that go through the check on line 1255
>>
>> I tried reproducing the hang with "log enable lldb process" and
>>generated
>> the attached log file. The part that's curious is right before the hang,
>> I'm seeing:
>>
>> Process::WaitForEventsPrivate (timeout = (nil), event_sp)...
>> Process::SetPublicState (stopped)
>> Process::SetPublicState (stopped) -- unlocking run lock
>> Process::WaitForStateChangedEvents (timeout = (nil), event_sp) =>
>>stopped
>> Process::Resume -- locking run lock
>> Process::Resume: -- WriteTryLock failed, not resuming.
>> Process::WaitForStateChangedEvents (timeout = (nil), event_sp)...
>
>That explains why the test is hanging, since we tried to resume, but
>failed, and then of course you're never going to get another event ever...
>
>So the next thing to figure out is who is calling this failing Resume.
>If you can debug this and break on point in Resume where we fail to get
>the write lock, we should be able to see who is trying this resume.
>Then we should look at whether in this case we can do something more
>intelligent than just silently not resume in this case. And also why we
>didn't get the run lock when we thought we should be able to.
>
>This is sort of back to our discussion about resuming and the run lock
>from a couple of weeks back. I've been trying to get my thoughts about
>this clearer. We have a couple of types of resumes, really: There's the
>"I want to be the one who starts a user level resume" type resumes.
>That's like the SBProcess::Step type commands.
>
>Then there are places where we resume on somebody else's behalf. The
>step plans when they resume for various reasons (for single stepping, or
>after hitting a step through or step out breakpoint), and the breakpoint
>condition resumes are examples of this.
>
>And to make things more confusing, there are "resumes when we are
>pretending that we aren't resuming". An example of the latter is when you
>go to run a function. When you go to call a function, you want to say "I
>want to make sure the target stays stopped" then you call down into
>EvaluateExpression which is going to run the target, but again on your
>behalf.
>
>Presently the two different types of resume are distinguished by whether
>we call Resume (a user level resume) or PrivateResume, which is done on
>somebody else's behalf. I think the problem is that there are places
>where which type of resume you intend is situational, so you can't tell
>just by where in the code you happen to be. There needs to be some
>explicit granting of authority, so we can track this better. At least
>that's the place where my thoughts are at present...
>
>Anyway, if you can see what is going on when this resume fails, that will
>help figure out what to do about it.
>
>Jim
>
>
>>
>>
>>
>>
>> Any thoughts?
>>
>> Dan
>>
>>
>>
>> On 2013-05-02 4:38 PM, "jingham at apple.com" <jingham at apple.com> wrote:
>>
>>> I'm confused. In Process::WaitForProcessToStop, (line 1255 seq.), I
>>>see:
>>>
>>> case eStateStopped:
>>> if
>>> (Process::ProcessEventData::GetRestartedFromEvent(event_sp.get()))
>>> continue;
>>> else
>>> return state;
>>>
>>> Is that not working somehow?
>>>
>>> Jim
>>>
>>>
>>> On May 2, 2013, at 12:24 PM, "Malea, Daniel" <daniel.malea at intel.com>
>>> wrote:
>>>
>>>> I looked into the hanging case a little more today. It seems that (as
>>>> per
>>>> the stack trace below) the hang is taking place in
>>>> Process::WaitForProcessToStop() when the process state (returned by
>>>> GetState) is eStateStopped.
>>>>
>>>> It seems that if the state is stopped, that function is guaranteed to
>>>> wait
>>>> forever for new events (which never come)Š I tried a quick fix that
>>>> added
>>>> such a check, but that caused other problems (unexpected process exit
>>>> was
>>>> reported).
>>>>
>>>> Is my fix along the below lines correct? Or is the
>>>> WaitForProcessToStop()
>>>> indeed correct the way it's implemented? Maybe there's extra events
>>>>that
>>>> get generated on Mac OS X while a process is stopped; thereby
>>>>preventing
>>>> the wait-forever situation?
>>>>
>>>> --- a/source/Target/Process.cpp
>>>> +++ b/source/Target/Process.cpp
>>>> @@ -1238,6 +1238,11 @@ Process::WaitForProcessToStop (const TimeValue
>>>> *timeout, lldb::EventSP *event_sp
>>>> if (state == eStateDetached || state == eStateExited)
>>>> return state;
>>>>
>>>> + // If we are already stopped, return now otherwise we wait
>>>>forever
>>>> + if (state == eStateStopped
>>>> + && !
>>>> Process::ProcessEventData::GetRestartedFromEvent(event_sp_ptr->get()))
>>>> + return state;
>>>> +
>>>>
>>>>
>>>>
>>>> Any hints appreciated :)
>>>>
>>>> Cheers,
>>>> Dan
>>>>
>>>>
>>>>
>>>> On 2013-05-01 10:41 PM, "jingham at apple.com" <jingham at apple.com> wrote:
>>>>
>>>>> Daniel,
>>>>>
>>>>> This test runs just fine on Mac OS X with the change I made, so it
>>>>>is a
>>>>> little surprising that it causes problems on Linux. After all, the
>>>>> change is all in generic execution control code.
>>>>>
>>>>> I looked at the effects of this change in a little more detail, and
>>>>>it
>>>>> was uncovering one unrelated bug. That was in how the "step over"
>>>>>plan
>>>>> works when it is using the "run to next range breakpoint". When it
>>>>>hit
>>>>> the next range breakpoint, it would correctly understand that it had
>>>>> explained the stop when asked in ShouldStop, but then it deleted the
>>>>> breakpoint, so that when it got asked again in ShouldReportStop, it
>>>>> thought it didn't explain the stop. So the Base thread plan would
>>>>>get
>>>>> asked ShouldReportStop instead.
>>>>>
>>>>> The change in this patch makes it so that the Base thread plan now
>>>>>does
>>>>> something when asked ShouldReportStop. This was required because if
>>>>>we
>>>>> get a stop which auto-resumes (for instance a Signal which you are
>>>>>not
>>>>> going to stop at but do want to print OR a breakpoint whose condition
>>>>> or
>>>>> command auto-continues) when we're doing nothing in particular, or
>>>>>when
>>>>> we stop for a reason not explained by any of the plans higher on the
>>>>> stack, then it will cause a "Stopped and restarted" event to get
>>>>> posted.
>>>>> Before it was silently eating those events which was wrong.
>>>>>
>>>>> So the result of the bug in how the "step over" plan works with the
>>>>> patch
>>>>> in place, meant that we were getting a few extraneous "stopped and
>>>>> restarted" events. This didn't cause any problems on Mac OS X (the
>>>>> test
>>>>> case you mention runs fine there.) And indeed that's not surprising.
>>>>> When doing a "step over" you might get all sorts of stopped &
>>>>>restarted
>>>>> events, from signals or auto-continued breakpoints, for instance.
>>>>> Whoever is running the event loop (e.g. the lldb driver) should
>>>>>notify
>>>>> the user about them (or not - often we just ignore them to keep from
>>>>> being overly chatty) and then go on its way.
>>>>>
>>>>> So I can (and will) fix it so that you don't get these extraneous
>>>>> "stopped and restarted" events. They cause unnecessary noise. And
>>>>> doing
>>>>> that will most likely make this test case stop hanging. But that
>>>>> doesn't
>>>>> really make me feel any better, since the main lldb execution control
>>>>> logic should have withstood them no problem (as it did on OS X), and
>>>>>in
>>>>> other circumstances it will have to.
>>>>>
>>>>> I don't have the time to look into why the Linux port horks up on
>>>>> these,
>>>>> but it is something interesting to investigate...
>>>>>
>>>>> Jim
>>>>>
>>>>>
>>>>> On May 1, 2013, at 9:03 AM, "Malea, Daniel" <daniel.malea at intel.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Jim, this commit seems to cause some hangs in
>>>>>> TestTypeCompletion.py,
>>>>>> can you take a look (or revert) please. I can provide
>>>>>>
>>>>>>
>>>>>>http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang/builds/275
>>>>>>4
>>>>>>
>>>>>> #0 pthread_cond_wait@@GLIBC_2.3.2 () at
>>>>>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
>>>>>> #1 0x00007f8801b2d8f7 in lldb_private::Condition::Wait
>>>>>> (this=0x1b52b80,
>>>>>> mutex=..., abstime=0x0, timed_out=0x7fff766e985e) at
>>>>>> ../tools/lldb/source/Host/common/Condition.cpp:92
>>>>>> #2 0x00007f8801b2c8a5 in
>>>>>> lldb_private::Predicate<bool>::WaitForValueEqualTo (this=0x1b52b50,
>>>>>> value=true, abstime=0x0, timed_out=0x7fff766e985e) at
>>>>>> ../tools/lldb/include/lldb/Host/Predicate.h:338
>>>>>> #3 0x00007f8801b66e82 in
>>>>>> lldb_private::Listener::WaitForEventsInternal
>>>>>> (this=0x1b52ab8, timeout=0x0, broadcaster=0x1cabd48,
>>>>>> broadcaster_names=0x0, num_broadcaster_names=0, event_type_mask=3,
>>>>>> event_sp=...) at ../tools/lldb/source/Core/Listener.cpp:433
>>>>>> #4 0x00007f8801b66f74 in
>>>>>> lldb_private::Listener::WaitForEventForBroadcasterWithType
>>>>>> (this=0x1b52ab8, timeout=0x0, broadcaster=0x1cabd48,
>>>>>> event_type_mask=3,
>>>>>> event_sp=...) at ../tools/lldb/source/Core/Listener.cpp:464
>>>>>> #5 0x00007f8801d152fd in
>>>>>> lldb_private::Process::WaitForStateChangedEvents
>>>>>> (this=0x1cabd10, timeout=0x0, event_sp=...) at
>>>>>> ../tools/lldb/source/Target/Process.cpp:1319
>>>>>> #6 0x00007f8801d1503b in
>>>>>>lldb_private::Process::WaitForProcessToStop
>>>>>> (this=0x1cabd10, timeout=0x0, event_sp_ptr=0x0) at
>>>>>> ../tools/lldb/source/Target/Process.cpp:1224
>>>>>> #7 0x00007f8801ecbce5 in
>>>>>> CommandObjectThreadStepWithTypeAndScope::DoExecute (this=0x1b892c0,
>>>>>> command=..., result=...) at
>>>>>> ../tools/lldb/source/Commands/CommandObjectThread.cpp:542
>>>>>> #8 0x00007f8801c57be9 in lldb_private::CommandObjectParsed::Execute
>>>>>> (this=0x1b892c0, args_string=0x7f88003cb4d8 "", result=...) at
>>>>>> ../tools/lldb/source/Interpreter/CommandObject.cpp:969
>>>>>> #9 0x00007f8801c4bea2 in
>>>>>> lldb_private::CommandInterpreter::HandleCommand
>>>>>> (this=0x1b52cf0, command_line=0x7f8807d0fd14 "next",
>>>>>> lazy_add_to_history=lldb_private::eLazyBoolNo, result=...,
>>>>>> override_context=0x0, repeat_on_empty_command=true,
>>>>>> no_context_switching=false)
>>>>>> at ../tools/lldb/source/Interpreter/CommandInterpreter.cpp:1813
>>>>>> #10 0x00007f8801a75a7b in lldb::SBCommandInterpreter::HandleCommand
>>>>>> (this=0x1c338b0, command_line=0x7f8807d0fd14 "next", result=...,
>>>>>> add_to_history=false) at
>>>>>> ../tools/lldb/source/API/SBCommandInterpreter.cpp:122
>>>>>> #11 0x00007f88019ee5dd in
>>>>>> _wrap_SBCommandInterpreter_HandleCommand__SWIG_1
>>>>>> (args=(<SBCommandInterpreter(this=<SwigPyObject at remote
>>>>>>0x1c5d3c0>)
>>>>>> at
>>>>>> remote 0x1c53050>, 'next', <SBCommandReturnObject(this=<SwigPyObject
>>>>>> at
>>>>>> remote 0x1c5d3f0>) at remote 0x1c53090>))
>>>>>> at tools/lldb/scripts/LLDBWrapPython.cpp:9180
>>>>>> #12 0x00007f88019ee7ce in _wrap_SBCommandInterpreter_HandleCommand
>>>>>> (self=0x0, args=(<SBCommandInterpreter(this=<SwigPyObject at remote
>>>>>> 0x1c5d3c0>) at remote 0x1c53050>, 'next',
>>>>>> <SBCommandReturnObject(this=<SwigPyObject at remote 0x1c5d3f0>) at
>>>>>> remote
>>>>>> 0x1c53090>))
>>>>>> at tools/lldb/scripts/LLDBWrapPython.cpp:9215
>>>>>> #13 0x0000000000463ea7 in ext_do_call (nk=29085856, na=<optimized
>>>>>> out>,
>>>>>> flags=<optimized out>, pp_stack=0x7fff766ea090, func=<built-in
>>>>>> function
>>>>>> SBCommandInterpreter_HandleCommand>) at ../Python/ceval.c:4331
>>>>>> #14 PyEval_EvalFrameEx (f=f at entry=
>>>>>> Frame 0x1c92540, for file
>>>>>>
>>>>>>
>>>>>>
>>>>>>/home/daniel/dev/llvm/build/lib/python2.7/site-packages/lldb/__init__
>>>>>>.p
>>>>>> y,
>>>>>> line 1633, in HandleCommand
>>>>>> (self=<SBCommandInterpreter(this=<SwigPyObject
>>>>>> at remote 0x1c5d3c0>) at remote 0x1c53050>, args=('next',
>>>>>> <SBCommandReturnObject(this=<SwigPyObject at remote 0x1c5d3f0>) at
>>>>>> remote
>>>>>> 0x1c53090>)), throwflag=throwflag at entry=0) at ../Python/ceval.c:2705
>>>>>> #15 0x0000000000467209 in PyEval_EvalCodeEx (co=0x1a5a930,
>>>>>> globals=<optimized out>, locals=locals at entry=0x0, args=<optimized
>>>>>> out>,
>>>>>> argcount=argcount at entry=3, kws=0x1c924c8, kwcount=0, defs=0x0,
>>>>>> defcount=0,
>>>>>> closure=closure at entry=0x0) at ../Python/ceval.c:3253
>>>>>> #16 0x000000000045ff77 in fast_function (nk=<optimized out>, na=3,
>>>>>> n=<optimized out>, pp_stack=0x7fff766ea320, func=<function at remote
>>>>>> 0x1973c80>) at ../Python/ceval.c:4117
>>>>>> #17 call_function (oparg=<optimized out>, pp_stack=0x7fff766ea320)
>>>>>>at
>>>>>> ../Python/ceval.c:4042
>>>>>> #18 PyEval_EvalFrameEx (f=f at entry=
>>>>>> Frame 0x1c922f0, for file
>>>>>> /home/daniel/dev/llvm/tools/lldb/test/lldbtest.py, line 1354, in
>>>>>> runCmd
>>>>>> (self=<TypeCompletionTestCase(subprocesses=[],
>>>>>> doTearDownCleanups=False,
>>>>>> lldbOption='--no-lldbinit', hooks=[<function at remote 0x1c55b18>],
>>>>>> __failed__=False, dbg=<SBDebugger(this=<SwigPyObject at remote
>>>>>> 0x1b91fc0>)
>>>>>> at remote 0x1af4a90>, _cleanups=[], session=<StringIO(softspace=0,
>>>>>> buflist=['\nos command: [[\'/bin/sh\', \'-c\', \'make clean; make
>>>>>> MAKE_DSYM=NO ARCH=x86_64 CC=clang\']]\nwith pid: 3076\nstdout: rm
>>>>>>-rf
>>>>>> "a.out" "" main.o main.d \nclang++ -g -O0 -m64 -c -o main.o
>>>>>> main.cpp\nclang++ main.o -g -O0 -m64 -o "a.out"\n\nstderr:
>>>>>> \nretcode:
>>>>>> 0\n\n', '\n', "runCmd: file a.out\noutput: Current executable set to
>>>>>> 'a.out' (x86_64).\n\n", '\n', 'runCmd: breakpoint set -f "main.cpp"
>>>>>>-l
>>>>>> 37\noutput: Breakpoint 1: 2 locations.\n\n', '\n', 'Expecting
>>>>>>pattern:
>>>>>> ^Breakpoint (?P<bpno>[0-9]+): (?P<num_locations>[0-9]+)
>>>>>> locations\\.$\nMatched\n', '\n', "runCmd: run\noutput: Process 3102
>>>>>> launched: '/home/daniel/dev/llv...(truncated),
>>>>>> throwflag=throwflag at entry=0) at ../Python/ceval.c:2666
>>>>>> #19 0x0000000000467209 in PyEval_EvalCodeEx (co=0x1b900b0,
>>>>>> globals=<optimized out>, locals=locals at entry=0x0, args=<optimized
>>>>>> out>,
>>>>>> argcount=argcount at entry=2, kws=0x1c913c8, kwcount=0, defs=0x19aae78,
>>>>>> defcount=3, closure=closure at entry=0x0) at ../Python/ceval.c:3253
>>>>>> #20 0x000000000045ff77 in fast_function (nk=<optimized out>, na=2,
>>>>>> n=<optimized out>, pp_stack=0x7fff766ea5b0, func=<function at remote
>>>>>> 0x1b94aa0>) at ../Python/ceval.c:4117
>>>>>> #21 call_function (oparg=<optimized out>, pp_stack=0x7fff766ea5b0)
>>>>>>at
>>>>>> ../Python/ceval.c:4042
>>>>>> #22 PyEval_EvalFrameEx (f=f at entry=
>>>>>> Frame 0x1c91200, for file
>>>>>>
>>>>>>
>>>>>>
>>>>>>/home/daniel/dev/llvm/tools/lldb/test/functionalities/type_completion
>>>>>>/T
>>>>>> es
>>>>>> tT
>>>>>> ypeCompletion.py, line 65, in type_completion_commands
>>>>>> (self=<TypeCompletionTestCase(subprocesses=[],
>>>>>> doTearDownCleanups=False,
>>>>>> lldbOption='--no-lldbinit', hooks=[<function at remote 0x1c55b18>],
>>>>>> __failed__=False, dbg=<SBDebugger(this=<SwigPyObject at remote
>>>>>> 0x1b91fc0>)
>>>>>> at remote 0x1af4a90>, _cleanups=[], session=<StringIO(softspace=0,
>>>>>> buflist=['\nos command: [[\'/bin/sh\', \'-c\', \'make clean; make
>>>>>> MAKE_DSYM=NO ARCH=x86_64 CC=clang\']]\nwith pid: 3076\nstdout: rm
>>>>>>-rf
>>>>>> "a.out" "" main.o main.d \nclang++ -g -O0 -m64 -c -o main.o
>>>>>> main.cpp\nclang++ main.o -g -O0 -m64 -o "a.out"\n\nstderr:
>>>>>> \nretcode:
>>>>>> 0\n\n', '\n', "runCmd: file a.out\noutput: Current executable set to
>>>>>> 'a.out' (x86_64).\n\n", '\n', 'runCmd: breakpoint set -f "main.cpp"
>>>>>>-l
>>>>>> 37\noutput: Breakpoint 1: 2 locations.\n\n', '\n', 'Expecting
>>>>>>pattern:
>>>>>> ^Breakpoint (?P<bpno>[0-9]+): (?P<num_locations>[0-9]+)
>>>>>> locations\\.$\nMatched\n', '\n', "runCmd:...(truncated),
>>>>>> throwflag=throwflag at entry=0) at ../Python/ceval.c:2666
>>>>>> #23 0x0000000000467209 in PyEval_EvalCodeEx (co=0x1af2e30,
>>>>>> globals=<optimized out>, locals=locals at entry=0x0, args=<optimized
>>>>>> out>,
>>>>>> argcount=argcount at entry=1, kws=0x0, kwcount=0, defs=0x0, defcount=0,
>>>>>> closure=closure at entry=0x0) at ../Python/ceval.c:3253
>>>>>> #24 0x000000000045ff77 in fast_function (nk=<optimized out>, na=1,
>>>>>> n=<optimized out>, pp_stack=0x7fff766ea840, func=<function at remote
>>>>>> 0x1ba1b18>) at ../Python/ceval.c:4117
>>>>>> #25 call_function (oparg=<optimized out>, pp_stack=0x7fff766ea840)
>>>>>>at
>>>>>> ../Python/ceval.c:4042
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Dan
>>>>>>
>>>>>> On 2013-04-30 7:42 PM, "Jim Ingham" <jingham at apple.com> wrote:
>>>>>>
>>>>>>> Author: jingham
>>>>>>> Date: Tue Apr 30 18:42:24 2013
>>>>>>> New Revision: 180829
>>>>>>>
>>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=180829&view=rev
>>>>>>> Log:
>>>>>>> Make "process handle -n true -s false" actually notifies of the
>>>>>>> signal.
>>>>>>>
>>>>>>> rdar://problem/12020085
>>>>>>>
>>>>>>> Modified:
>>>>>>> lldb/trunk/include/lldb/Target/ThreadPlanBase.h
>>>>>>> lldb/trunk/source/Target/ThreadPlanBase.cpp
>>>>>>>
>>>>>>> Modified: lldb/trunk/include/lldb/Target/ThreadPlanBase.h
>>>>>>> URL:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/T
>>>>>>>hr
>>>>>>> ea
>>>>>>> dP
>>>>>>> lanBase.h?rev=180829&r1=180828&r2=180829&view=diff
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>====================================================================
>>>>>>>==
>>>>>>> ==
>>>>>>> ==
>>>>>>> ====
>>>>>>> --- lldb/trunk/include/lldb/Target/ThreadPlanBase.h (original)
>>>>>>> +++ lldb/trunk/include/lldb/Target/ThreadPlanBase.h Tue Apr 30
>>>>>>> 18:42:24
>>>>>>> 2013
>>>>>>> @@ -37,6 +37,7 @@ public:
>>>>>>> virtual bool ValidatePlan (Stream *error);
>>>>>>> virtual bool PlanExplainsStop (Event *event_ptr);
>>>>>>> virtual bool ShouldStop (Event *event_ptr);
>>>>>>> + virtual Vote ShouldReportStop (Event *event_ptr);
>>>>>>> virtual bool StopOthers ();
>>>>>>> virtual lldb::StateType GetPlanRunState ();
>>>>>>> virtual bool WillStop ();
>>>>>>>
>>>>>>> Modified: lldb/trunk/source/Target/ThreadPlanBase.cpp
>>>>>>> URL:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadP
>>>>>>>la
>>>>>>> nB
>>>>>>> as
>>>>>>> e.cpp?rev=180829&r1=180828&r2=180829&view=diff
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>====================================================================
>>>>>>>==
>>>>>>> ==
>>>>>>> ==
>>>>>>> ====
>>>>>>> --- lldb/trunk/source/Target/ThreadPlanBase.cpp (original)
>>>>>>> +++ lldb/trunk/source/Target/ThreadPlanBase.cpp Tue Apr 30 18:42:24
>>>>>>> 2013
>>>>>>> @@ -78,6 +78,22 @@ ThreadPlanBase::PlanExplainsStop (Event
>>>>>>> return true;
>>>>>>> }
>>>>>>>
>>>>>>> +Vote
>>>>>>> +ThreadPlanBase::ShouldReportStop(Event *event_ptr)
>>>>>>> +{
>>>>>>> + StopInfoSP stop_info_sp = GetPrivateStopReason();
>>>>>>> + if (stop_info_sp)
>>>>>>> + {
>>>>>>> + bool should_notify =
>>>>>>>stop_info_sp->ShouldNotify(event_ptr);
>>>>>>> + if (should_notify)
>>>>>>> + return eVoteYes;
>>>>>>> + else
>>>>>>> + return eVoteNoOpinion;
>>>>>>> + }
>>>>>>> + else
>>>>>>> + return eVoteNoOpinion;
>>>>>>> +}
>>>>>>> +
>>>>>>> bool
>>>>>>> ThreadPlanBase::ShouldStop (Event *event_ptr)
>>>>>>> {
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> lldb-commits mailing list
>>>>>>> lldb-commits at cs.uiuc.edu
>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>>>
>>
>> <180829_process_lock_hang.txt>
>
More information about the lldb-commits
mailing list