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

[Sahil Siddiq]

Hi,

On Wednesday, 29 March 2023 00:54:47 IST Dmitry V. Levin wrote:
> 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).

Ok, I understand this now.

> > 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.

Oh, alright. I had implemented it in a way that keeps strace as the parent of the tracees
even after they are detached. That's why I thought the second run alone should take a
minute. That implementation was based on the implementation for "-b execve". But
given that -b is for a single tracee while -l is global, I don't think it would make sense to
implement it as such.

I'll make the changes and send in a new patch.

Thanks,
Sahil