[lldb-dev] [PATCH] Unexpected group-stop with threading under Linux

[Todd Fiala]

I'm giving this a shot now locally.  The change looks reasonable to me -
any ptrace experts disagree?

The one bit I'm not entirely sure about is: if assertions are disabled, and
for some reason the WSTOPSIG(status) is not SIGSTOP (since we're not
explicitly checking before the Resume(wait_pid, SIGSTOP) call), how badly
can that gunk things up?  An if check before the Resume call would at least
stop the wrong signal from getting sent to the inferior if I'm reading it
right.


On Mon, Jan 27, 2014 at 2:47 AM, Andrew MacPherson <andrew.macp at gmail.com>wrote:

> This patch addresses a bug where in a multi-threaded program a new signal
> from the inferior may be received before all group-stop messages from an
> earlier signal have been handled. The attached .cpp file exposes the issue:
>
>    - clang++ -o thread thread.cpp -lpthread -g -O0
>    - lldb ./thread
>    - r
>    - hit Ctrl-C
>    - br set -f thread.cpp -l 11
>    - c
>    - <hang>
>
> A breakpoint is usually hit before all the group-stop messages involved in
> restarting the process are handled and the internal state then gets out of
> sync.
>
> The attached patch solves the issue and all unit tests pass, I'm not a
> ptrace expert though so there may be a more appropriate fix. The group-stop
> handling was taken from the existing ProcessMonitor::MonitorCallback.
>
> Thanks,
>
> Andrew
>
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140127/3feae1e0/attachment.html>