proot 4.0.3 ptrace layer.

[milky...@gmail.com]

Hi.

I'm using proot 4.0.3 and try to use gdb/strace within proot.
Simple programs seem to work just fine. Most multithreaded programs do not.
I see that some PTRACE_* options are missing, but that should not affect multithreaded programs?
I notice that even ctrl-c does not send an interrupt to gdb/strace so the program "hangs".
Does sigwaiting multithreaded programs break signal handling through ptrace?
The sigwaiting program will never see the sigint delivered (only dequeued), i.e never been delivered to the thread, i.e no reaction by gdb/strace.

Regards,
Christian

[Cédric VINCENT]

Hello Christian,

On Mon, Oct 27, 2014 at 12:21 PM, <milky...@gmail.com> wrote:
> I'm using proot 4.0.3 and try to use gdb/strace within proot.
> Simple programs seem to work just fine. Most multithreaded programs
> do not.

You are right, the ptrace emulation layer in PRoot doesn't work well
with multithreaded programs.  I never tested this use case (hum!).

> I see that some PTRACE_* options are missing, but that
> should not affect multithreaded programs?

I don't think the bug comes from that, too.

> I notice that even ctrl-c does not send an interrupt to gdb/strace
> so the program "hangs".

To me this is just a side effect of this bug, ie. ctrl-c will work
correctly once multithreaded programs are correctly supported under
the ptrace emulation layer.

> Does sigwaiting multithreaded programs break signal handling through
> ptrace?  The sigwaiting program will never see the sigint delivered
> (only dequeued), i.e never been delivered to the thread, i.e no
> reaction by gdb/strace.

I don't know yet.  I filled a ticket in PRoot's issue tracker on your
behalf: https://github.com/cedric-vincent/PRoot/issues/69

Thanks for the bug report,
Cédric.

[milky...@gmail.com]

I don't know yet.  I filled a ticket in PRoot's issue tracker on your
behalf: https://github.com/cedric-vincent/PRoot/issues/69

Thanks for the bug report,
Cédric.

Any progress Cédric? Or Ideas? The testcase is so simple that I doubt I can help,
but I sure can test it later on in more complex multithreaded environments.

Regards,
Christian

[Cédric VINCENT]

Hello Christian,

On Wed, Nov 5, 2014 at 12:50 PM, <milky...@gmail.com> wrote:
>
> Any progress Cédric? Or Ideas? The testcase is so simple that I
> doubt I can help, but I sure can test it later on in more complex
> multithreaded environments.

Sorry, I didn't take a look yet. I'm preparing of the next version of
PRoot (v5.0), so could you remind me this issue once it is released?

Regards,
Cédric.

[Cédric VINCENT]

Hello Christian,

On Wed, Nov 5, 2014 at 12:50 PM, <milky...@gmail.com> wrote:

> Any progress Cédric? Or Ideas? The testcase is so simple that I

> doubt I can help, but I sure can test it later on in more complex
> multithreaded environments.

This has been fixed by commit c47aeb7d in the next branch of PRoot:

https://github.com/cedric-vincent/PRoot/commit/c47aeb7d1c8da0e2ff58bbeb75abe0d7c23a26ee
https://github.com/cedric-vincent/PRoot/tree/next

This commit will be shipped in the next release of PRoot (v5.1.0),
maybe by the end of this month.

Thanks for your bug report and your patience,
Cédric.

[henrikw...@gmail.com]

Hi Cedric,

I did a quick test today with this commit and using "gdb <application>" seems to work good :)

But when I try to attach to a running application (gdb -p <pid>) I never get the gdb prompt.

gdb reads a lot of debug information from various shared libraries etc, but then seems stuck in a similar way as was the case before.

I didn't try it so much so not sure if it always fails or just for certain applications.

thanks,

/ Henrik

[Cédric VINCENT]

Hello Henrik,

> But when I try to attach to a running application (gdb -p <pid>) I
> never get the gdb prompt.

I have to admit I didn't make any efforts to make "gdb -p" work. Even
worst I know that ptrace-attach doesn't work with some other programs:

https://github.com/cedric-vincent/PRoot/issues/68

Although I'll take a look at this issue tomorrow to check if I can get
a fix before starting to validate the upcoming release (v5.1.0).

Nonetheless you have to be aware about this limitation: a process
*not* managed by PRoot will not be able to attach a process managed by
PRoot. In other words, a PRoot-ed process can't be attached by a
process which is *not* PRoot-ed (the other way should be technically
possible but it is not implemented yet).

Regards,
Cédric.

[Cédric VINCENT]

> Nonetheless you have to be aware about this limitation: a process
> *not* managed by PRoot will not be able to attach a process managed
> by PRoot. In other words, a PRoot-ed process can't be attached by a

> process which is *not* PRoot-ed.

I forgot to mention the most important point: both gdb and the
attached process(es) have to be managed by the same instance of PRoot.

In this case, you may wish to use a terminal multiplexer under PRoot,
that way all new sessions/windows/processes will be managed by the
same instance of PRoot. For instance, with tmux:

proot [...] tmux -L "prooted"

Note that the -L option of tmux is used to ensure a whole new server
is started under PRoot, otherwise it might connect to a server already
running outside of the current PRoot domain/namespace.

Cédric.

[Cédric VINCENT]

> But when I try to attach to a running application (gdb -p <pid>) I
> never get the gdb prompt.

I did some tests against commit 73ba10b8 and I was able to attach and
debug a simple mono-threaded program and a simple multi-threaded
program too. The only bug I hit is programs are left in the stopped
state when GDB detaches.

Henrik, could you please send me more details (versions, logs, ...)?

Cédric.

[Henrik Wallin]

> Henrik, could you please send me more details (versions, logs, ...)?

Hi,

My setup is a bit complex. The process tree looks something like this:

- <wrapper script>

   +-  proot ... alot of options...

       +- <another wrapper script>

          +- daemon1

          +- ...

          +- daemonN

          +- bash

             +- applications, etc

From the bash I launch the multi-threaded application.

It works good if I do "gdb <app>".

If I do "<app> &", and then "gdb <pid>", gdb freezes.

After that I can not manage to kill that gdb, Neither from inside proot or from outside.

Killing the application doesn't "free" gdb either.

gdb is in "t+" state in ps. "tracing stopped"

It is only if I force kill proot that the gdb actually dies.

The application and all shared libraries inside proot have debug symbols so gdb reads up a lot of debug information. Not sure if that matters or not.

But as it seems to work with "gdb <app>" I guess that should be ok.

I'm not sure what kind of logs would be interesting in this scenario?

Proot: Build from c47aeb7d1c8da0e2ff58bbeb75abe0d7c23a26ee

gdb: 7.6

--

/  Henrik

[Henrik Wallin]

Trying some other variants and I succeed with all single-threaded apps, but fail with any multi-threaded apps.

And I can see that the application is running, so gdb have not come as far as to stop the application.

I tried a simple application that is linked with pthread. If started without args it never starts a thread and in that case gdb works.

If I start the testapp with some arguments it will create threads, then gdb -p does not work.

Let me know what I can do to help.

thanks,

/ Henrik

--

/  Henrik

[Cédric VINCENT]

I'm now able to reproduce it, thanks!

[Cédric VINCENT]

On Thu, Dec 11, 2014 at 10:19 AM, Henrik Wallin
<henrikw...@gmail.com> wrote:
> But as it seems to work with "gdb <app>" I guess that should be ok.

Good news :) because even if I think I understand what the issue is
[1], a fix would require modifications I don't want to make before
releasing PRoot v5.1.0.

Regards,
Cédric.

[1] https://github.com/cedric-vincent/PRoot/issues/77