[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 12:24:19 PDT 2013


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/2754
>> 
>> #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__.py,
>> 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/Tes
>>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/Threa
>>>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/ThreadPlanB
>>>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
>





More information about the lldb-commits mailing list