[Lldb-commits] [lldb] r180829 - Make "process handle -n true -s false" actually notifies of the signal.

jingham at apple.com jingham at apple.com
Thu May 2 13:38:22 PDT 2013 

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/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