[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 14:06:38 PDT 2013
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)...
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/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__.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/Thr
>>>>>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/ThreadPla
>>>>>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
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 180829_process_lock_hang.txt
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20130502/b58849e5/attachment.txt>
More information about the lldb-commits
mailing list