[Qemu-devel] Why not use exit() instead of abort()?

[Qemu-devel] Why not use exit() instead of abort()?

[Bernhard Kauer]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

There are a couple of places in qemu, where abort() is called.
The most commonly used one is perhaps cpu_abort() which is called
e.g. when a triple fault occures.

As abort() does not call any atexit() function, cleanup is not
performed. This leaves for example the terminal in a state where
the cursor is invisible.

Are there any reasons not to use exit(1) in cpu_abort()?


	Bernhard Kauer

[-- Attachment #2: qemu_abort.diff --]
[-- Type: text/x-diff, Size: 398 bytes --]

Index: exec.c
===================================================================
RCS file: /sources/qemu/qemu/exec.c,v
retrieving revision 1.103
diff -u -r1.103 exec.c
--- exec.c	1 Jul 2007 18:21:11 -0000	1.103
+++ exec.c	4 Aug 2007 13:07:52 -0000
@@ -1301,7 +1301,7 @@
         fflush(logfile);
         fclose(logfile);
     }
-    abort();
+    exit(1);
 }
 
 CPUState *cpu_copy(CPUState *env)

Re: [Qemu-devel] Why not use exit() instead of abort()?

[Dan Shearer]

On Sun, Aug 05, 2007 at 11:13:55PM +0200, Bernhard Kauer wrote:
> There are a couple of places in qemu, where abort() is called.
> The most commonly used one is perhaps cpu_abort() which is called
> e.g. when a triple fault occures.
> 
> As abort() does not call any atexit() function, cleanup is not
> performed. 

Tiny correction: abort() and _exit don't call atexit(), however
unix-like OSs still cleanup memory and file descriptors and other
transient resources  anyway no matter how the program ended. So lack of
cleanup isn't quite as big an issue as it might seem.

> This leaves for example the terminal in a state where
> the cursor is invisible.

Non-transient resources such as DSOs and domain sockets are not cleaned
up by the OS, which accounts for the terminal problem you noticed.

> Are there any reasons not to use exit(1) in cpu_abort()?

Speed. I used to use abort() or _exit() for speed, ie they didn't hang
around while atexit() waited politely for timeouts. I thought if I told
the program to stop it should stop immediately :-)

Then I had all sorts of problems to do with persistent shared resources
hanging around in strange states so I moved to exit(1).

I think (can someone correct me here?) there is another reason to call
atexit() for portable programs, and that is that Microsoft OSs aren't as
fussy about cleaning up after a program has exited.

-- 
Dan Shearer
dan@shearer.org

Re: [Qemu-devel] Why not use exit() instead of abort()?

[Bernhard Kauer]

On Mon, Aug 06, 2007 at 07:21:21AM +0930, Dan Shearer wrote:
> On Sun, Aug 05, 2007 at 11:13:55PM +0200, Bernhard Kauer wrote:
> > There are a couple of places in qemu, where abort() is called.
> > The most commonly used one is perhaps cpu_abort() which is called
> > e.g. when a triple fault occures.
> > 
> > As abort() does not call any atexit() function, cleanup is not
> > performed. 
> 
> Tiny correction: abort() and _exit don't call atexit(), however
> unix-like OSs still cleanup memory and file descriptors and other
> transient resources  anyway no matter how the program ended. So lack of
> cleanup isn't quite as big an issue as it might seem.
> 
> > This leaves for example the terminal in a state where
> > the cursor is invisible.
> 
> Non-transient resources such as DSOs and domain sockets are not cleaned
> up by the OS, which accounts for the terminal problem you noticed.

Well, the problem is here that the function term_exit() is never
called, which would restore the terminal state to the old version
via a tcsetattr().


> > Are there any reasons not to use exit(1) in cpu_abort()?
> 
> Speed. I used to use abort() or _exit() for speed, ie they didn't hang
> around while atexit() waited politely for timeouts. I thought if I told
> the program to stop it should stop immediately :-)

I would use a 'kill -TERM' for that.


	Bernhard