qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] linux-user: Proper exit code for uncaught signa


From: Riku Voipio
Subject: Re: [Qemu-devel] [PATCH] linux-user: Proper exit code for uncaught signals
Date: Thu, 27 Nov 2008 14:44:06 +0200
User-agent: Mutt/1.5.11+cvs20060126

On Thu, Nov 27, 2008 at 12:16:15PM +0000, Jamie Lokier wrote:
> > > The proper exit code for dieing from an uncaught signal is -<signal>.
> > > The kernel doesn't allow exit() or _exit() to pass a negative value.
> > > To get the proper exit code we need to actually die from an uncaught
> > > signal.
> 
> It's nothing like -<signal>, so the comment should be changed.

Something like:

Proper exit code for dieing from an uncaught signal differs from normal
exit, so applications using WISIGNALED/WTERMSIG don't get the expected
result. The proper way is to actually die from an uncaught signal.

> The general principle of sending yourself a signal to get the right
> exit status is good.

> > > +    sigfillset(&act.sa_mask);
> > > +    act.sa_handler = SIG_DFL;
> > > +    sigaction(host_sig, &act, NULL);
> 
> What if the SIG_DFL _host_ behaviour is not to terminate the host
> process, but it has terminated the guest process?  Awkward one.

Could this happen on Linux or is this a portability issue?

> > > +    /* For some reason raise(host_sig) doesn't send the signal when
> > > +     * statically linked on x86-64. */
> > > +    kill(getpid(), host_sig);

> Is getpid() always right here, and should tgkill() or tkill() be used when
> clone is supported?

I'll have to look into this. The thought that this code needs to
do multithreaded signal handling (preferredly in a portable fashion)
feels like I'm heading towards endless swamplands..

-- 
"rm -rf" only sounds scary if you don't have backups




reply via email to

[Prev in Thread] Current Thread [Next in Thread]