> Don't you have the backtrace from libunwind that you could save from austinp
> itself?
Unfortunately no as the "deadlock" happens before any samples have a
chance to be collected. Upon further investigation, it seems that
trying to resume a thread over and over when ptrace fails takes quite
> On 6 Jun 2022, at 17:52, Gabriele wrote:
>
> I've found it hard to give an answer to this question. Because austinp
> is already tracing the interpreter, I cannot use, e.g., gdb to dump a
> backtrace.
Don't you have the backtrace from libunwind that you could save from austinp
itself?
> Do you know what is involved in the deadlock (as in, what the threads are
> waiting on)?
I've found it hard to give an answer to this question. Because austinp
is already tracing the interpreter, I cannot use, e.g., gdb to dump a
backtrace. The event is also quite rare and it seems to happen
On Mon, Jun 6, 2022 at 4:35 PM Gabriele wrote:
> The austinp variant is a variant of Austin
> (https://github.com/P403n1x87/austin) for Linux that uses ptrace to
> seize and interrupt/continue threads to capture native stack traces
> using libunwind. During testing, I have discovered that there
Hi Gabriele,
If everything you are doing is pausing and restarting, there should be no
reason
why this would interfere with anything more than if you are doing this at
any other time
other than the interpreter initialization. The only thing I can think of is
that at this stage
locking is much
