[RFC v1] [GSoC] Add test for -l/--syscall-limit option

[Dmitry V. Levin]

On Sat, Feb 25, 2023 at 09:47:34PM +0530, Sahil Siddiq wrote:
> On Friday, 24 February 2023 23:45:58 IST Dmitry V. Levin wrote:
[...]
> > Note that your --syscall-limit implementation detaches from the parent
> > process in a way that causes it to be killed by strace with SIGTERM,
> > so the remaining code is not reached.  I'm not sure you planned to
> > implement --syscall-limit this way, and I'm doubt that users would
> > expect such behavior.  This is also in contrast with --detach-on=execve
> > which also detaches its tracee but doesn't kill it, see detach_on_execve
> > handling in maybe_allocate_tcb().
> 
> No, it wasn't my intention to kill the tracee with SIGTERM on detaching. I'll take
> a look at --detach-on=execve to understand the detaching process better.
> 
> > > +       printf("+++ exited with 0 +++\n");
> > > +
> > > +       ppid = getpid();
> > > +       ppid = getppid();
> > > +       printf("%u getpid() = %d\n", pid, pid);
> > > +       printf("%u getppid() = %d\n", pid, ppid);
> > > +       printf("+++ exited with 0 +++\n");
> > > +       return WEXITSTATUS(status);
> > > +}
> >
> > So this code works unless executed under strace --syscall-limit.
> 
> Yes, this is what I expect when a process is started under strace with the
> --syscall-limit option (strace --syscall-limit=NUMBER process). But if the
> process is already running as a stand-alone process, and strace is attached
> to the process via the -p option, then I would expect the process to run to
> completion normally even after getting detached from strace.

When strace terminates, it detaches from all its tracees, but it also
terminates the process it started.  Besides that, it doesn't try to
terminate any other tracee.  See cleanup() for details.


-- 
ldv