[lldb][test] Skip TestConcurrentVFork on all Linux

And given that it is only for Linux - effectively skip it,
but in a way where we don't forget that it's Linux only.

See https://github.com/llvm/ll

[lldb][test] Skip TestConcurrentVFork on all Linux

And given that it is only for Linux - effectively skip it,
but in a way where we don't forget that it's Linux only.

See https://github.com/llvm/llvm-project/issues/85084.

This test times out on occasion on Arm, AArch64 and X86 Linux,
which I saw just today in a buildkite build. Causing a failure that
is 1. confusing because the PR wasn't for LLDB and 2. annoying
to find in the giant log file (which isn't the test's fault,
but it adds to the overhead).

It's probably important to have this test running somewhere but
right now it's causing too much noise to do so.

show more ...

[lldb][Test] Disable concurrent vfork tests on Arm and AArch64 Linux (again)

5f3e106de3cd5ce6d7ba37fb11f6ad740cb430c5 made them a lot more stable but
there are still occasions where they will timeou

[lldb][Test] Disable concurrent vfork tests on Arm and AArch64 Linux (again)

5f3e106de3cd5ce6d7ba37fb11f6ad740cb430c5 made them a lot more stable but
there are still occasions where they will timeout and leave behind stale
processes.

For example https://lab.llvm.org/buildbot/#/builders/96/builds/56699.

show more ...

[lldb/linux] Make sure the process continues running after a detach (#88494)

Fixes #85084

Whenever an inferior thread stops, lldb-server sends a SIGSTOP to all
other threads in the process to fo

[lldb/linux] Make sure the process continues running after a detach (#88494)

Fixes #85084

Whenever an inferior thread stops, lldb-server sends a SIGSTOP to all
other threads in the process to force them to stop as well. If those
threads stop on their own before they get a signal, this SIGSTOP will
remain pending and be delivered the next time the process resumes.

Normally, this is not a problem, because lldb-server will detect this
stale SIGSTOP and resume the process. However, if we detach from the
process while it has these SIGSTOPs pending, they will get immediately
delivered, and the process will remain stopped (most likely forever).

This patch fixes that by sending a SIGCONT just before detaching from
the process. This signal cancels out any pending SIGSTOPs, and ensures
it is able to run after we detach. It does have one somewhat unfortunate
side-effect that in that the process's SIGCONT handler (if it has one)
will get executed spuriously (from the process's POV).

This could be _sometimes_ avoided by tracking which threads got send a
SIGSTOP, and whether those threads stopped due to it. From what I could
tell by observing its behavior, this is what gdb does. I have not tried
to replicate that behavior here because it adds a nontrivial amount of
complexity and the result is still uncertain -- we still need to send a
SIGCONT (and execute the handler) when any thread stops for some other
reason (and leaves our SIGSTOP hanging). Furthermore, since SIGSTOPs
don't stack, it's also possible that our SIGSTOP/SIGCONT combination
will cancel a genuine SIGSTOP being sent to the debugger application (by
someone else), and there is nothing we can do about that. For this
reason I think it's simplest and most predictible to just always send a
SIGCONT when detaching, but if it turns out this is breaking something,
we can consider implementing something more elaborate.

One alternative I did try is to use PTRACE_INTERRUPT to suspend the
threads instead of a SIGSTOP. PTRACE_INTERUPT requires using
PTRACE_SEIZE to attach to the process, which also made this solution
somewhat complicated, but the main problem with that approach is that
PTRACE_INTERRUPT is not considered to be a signal-delivery-stop, which
means it's not possible to resume it while injecting another signal to
the inferior (which some of our tests expect to be able to do). This
limitation could be worked around by forcing the thread into a signal
delivery stop whenever we need to do this, but this additional
complication is what made me think this approach is also not worthwhile.

This patch should fix (at least some of) the problems with
TestConcurrentVFork, but I've also added a dedicated test for checking
that a process keeps running after we detach. Although the problem I'm
fixing here is linux-specific, the core functinoality of not stopping
after a detach should function the same way everywhere.

show more ...

[lldb][Test] Disable ConcurrentVFork tests on Arm/AArch64 Linux

They are either flaky, or not cleaning up after themselves.
See https://github.com/llvm/llvm-project/issues/85084.

Fix lldb crash while handling concurrent vfork() (#81564)

We got user reporting lldb crash while the debuggee is calling vfork()
concurrently from multiple threads.
The crash happens because the c

Fix lldb crash while handling concurrent vfork() (#81564)

We got user reporting lldb crash while the debuggee is calling vfork()
concurrently from multiple threads.
The crash happens because the current implementation can only handle
single vfork, vforkdone protocol transaction.

This diff fixes the crash by lldb-server storing forked debuggee's <pid,
tid> pair in jstopinfo which will be decoded by lldb client to create
StopInfoVFork for follow parent/child policy. Each StopInfoVFork will
later have a corresponding vforkdone packet. So the patch also changes
the `m_vfork_in_progress` to be reference counting based.

Two new test cases are added which crash/assert without the changes in
this patch.

---------

Co-authored-by: jeffreytan81 <jeffreytan@fb.com>

show more ...