[PATCH v3 3/3] Add tests for the -l/--syscall-limit option

[Dmitry V. Levin]

On Fri, Mar 03, 2023 at 01:00:23AM +0530, Sahil Siddiq wrote:
> Hi,
> 
> On Thursday, 2 March 2023 06:15:43 IST Dmitry V. Levin wrote:
> > On Thu, Mar 02, 2023 at 03:08:44AM +0530, Sahil Siddiq wrote:
> > [...]
> > 
> > > +		int pid = getpid();
> > > +		chdir(".");
> > > +
> > > +		printf("%-5u getpid() = %d\n", pid, pid);
> > > +		puts(" <detached ...>");
> > 
> > Note that " <detached ...>" is not prefixed by pid so there is no way
> > to tell the pid of process that has been detached.
> > In other words, this expected output demonstrates an inconsistency
> > in the output produced by this new option.
> 
> In the codebase, I noticed that "Process %u detached" is being printed
> using error_msg() which explicitly sends the output to stderr. Syscall
> decodings, on the other hand, are printed to tcp->outf. So, when using
> strace with the -o option, the  "Process %u detached" is not printed to
> the file.

Well, yes, this message is printed to stderr.

> In the tests that I have written for the -l option, when run_strace() is
> called in init.sh, the "Process %u detached" line will not be printed to
> $LOG.
> 
> Is it alright if these lines are omitted in $LOG when running the tests?

What these messages describe is not something the tracee is doing but what
strace is doing to the tracee, so I think it's correct these messages are
not going to the tracee log.  Let's say strace -ff -o $LOG -l $limit
is invoked, would it make sense to add the diagnostics about detaching
to every log file?  I don't think so.

Checking for these messages is one of possible methods to check that the
tracees were detached, but I suppose it's not the only way to check this.


-- 
ldv