Date: Mon, 15 Dec 2003 08:50:45 -0800 (PST) From: Doug White <dwhite@gumbysoft.com> To: Maxim Konovalov <maxim@macomnet.ru> Cc: Alexander Nedotsukov <bland@mail.ru> Subject: Re: truss issue Message-ID: <20031215084226.W81321@carver.gumbysoft.com> In-Reply-To: <20031215151613.E7304@news1.macomnet.ru> References: <3EEDD6E2.6040505@mail.ru> <20031215151613.E7304@news1.macomnet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Dec 2003, Maxim Konovalov wrote: > > I found current truss behaviour a bit strange. It coredumps always if > > trussed process do without any significant reason for my understanding. > > I also confused with comment for commit originally introduced this > > functionality > > http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/truss/main.c.diff?r1=1.9&r2=1.10. > > I propose patch attached to make truss always return result of trussed > > process and do not kill() itself. What do you think about it? > > As a matter of fact, bin/58970 is a backout of rev.1.10 truss/main.c: > > ---------------------------- > revision 1.10 > date: 1998/08/24 10:17:20; author: cracauer; state: Exp; lines: +9 -1 > When exiting on SIGINT, exit with signal status > ============================================================================= > > But a code does not match the comment and does something funny: > > @@ -216,6 +217,7 @@ > break; > case S_SIG: > fprintf(outfile, "SIGNAL %lu\n", pfs.val); > + sigexit = pfs.val; > break; > case S_EXIT: > fprintf (outfile, "process exit, rval = %lu\n", pfs.val); > @@ -232,5 +234,11 @@ > if (ioctl(Procfd, PIOCCONT, val) == -1) > warn("PIOCCONT"); > } while (pfs.why != S_EXIT); > + if (sigexit) { > + if (sigexit == SIGQUIT) > + exit(sigexit); > + (void) signal(sigexit, SIG_DFL); > + (void) kill(getpid(), sigexit); > + } > return 0; > } > > Gentlemen, does anobody know what is going on there? My reading of it is that it is truss hitting itself with the same signal that killed the process that it was tracing so that truss will exit showing that it was killed by a signal. So this is actually implementing the requested functionality. Processes that exit due to a signal don't return an exit code. It seems keyed on 'sigexit' whatever that is. SIGQUIT seems to be an exception. Hwever there maybe a bug since sigexit isn't cleared on every loop so it may be retaining a previous value and showing a signal exit when there hasn't been one. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031215084226.W81321>