[PATCH v5 1/3] Introduce -l/--syscall-limit option

[Dmitry V. Levin]

On Wed, Mar 29, 2023 at 12:24:48AM +0530, Sahil Siddiq wrote:
[...]
> I was going through the code that handles "-b execve" and I have one more query.
> If I am not mistaken, as soon as the "TE_STOP_BEFORE_EXECVE" event occurs, the
> tracees are detached in "dispatch_event". I was under the impression that the
> implementations of "-b execve" and -l are similar in this context. I haven't understood
> why "-b execve" doesn't give a problem because of this while -l may give a problem.

The main difference is that the effect of "-b execve" is per-tracee
(the tracee is detached when it invokes execve) while the effect of 
--syscall-limit is global (when the limit is reached, all tracees are
detached).

> On Sun, Mar 26, 2023 at 08:34:17PM +0530, Sahil Siddiq wrote:
> > On Sunday, 26 March 2023 16:06:04 IST Dmitry V. Levin wrote:
> > > On Sun, Mar 26, 2023 at 03:57:24PM +0530, Sahil Siddiq wrote:
> > > > Hi,
> > > >
> > > > Thank you for the feedback. There are a few things that I haven't
> > > > really understood.
> > > >
> > > > On Sunday, 26 March 2023 01:11:07 IST Dmitry V. Levin wrote:
> > > > > On Mon, Mar 20, 2023 at 11:10:56AM +0530, Sahil Siddiq wrote:
> > > > > [...]
> > > > > for example, a tracee
> > > > > doesn't invoke syscalls, strace -l won't finish.
> > > >
> > > > I didn't understand this example. In case the argument to -l is greater
> > > > than the number of syscalls that are invoked, wouldn't strace proceed
> > > > as usual? If the tracee does not invoke any syscall, the syscall_limit
> > > > counter will not decrease in syscall_exiting_trace().
> > >
> > > Here is an example: take your strace--syscall-limit.c test, insert sleep(60)
> > > right before the waitpid loop, and see what happens.
> >
> > I am still a bit confused. I inserted sleep(60) so that the test snippet now looks
> > like this:
> >
> >     sleep(60);
> >     while ((waitpid(child, &status, 0)) != child) {
> >         if (errno == EINTR)
> >             continue;
> >         perror_msg_and_fail("waitpid: %d", child);
> >     }
> >
> > I first ran the following command:
> >
> > strace --signal='!SIGCHLD,SIGCONT' --quiet=path-resolution -f -a 9 --trace=chdir,getpid --syscall-limit=3 ./strace--syscall-limit
> >
> > This gives the same output that I would expect. It prints only the first three syscalls
> > that were traced along with the "process <pid> attached/detached" log lines  and it
> > terminates after that.
> >
> > However, when running "bash ./strace--syscall-limit.test", the test indeed does not
> > terminate.
> 
> I was going through this test again and I just realized that it might be working as
> expected. I timed the test and realized that it takes exactly 2 minutes for the test
> to execute completely. The first minute is spent executing:
> 
>     run_prog > /dev/null
> 
> and the next minute is spent running:
> 
>     run_strace --signal='!SIGCHLD,SIGCONT' --quiet=path-resolution -f -a 9 "$@" $args > "$EXP"

The second run (under strace) shouldn't take one minute because strace is
expected to detach the tracee while it's waiting for its sleep(60) to
finish.


-- 
ldv