[Bug translator/5045] New: translator not cleaning up temporary directories

[Bug translator/5045] New: translator not cleaning up temporary directories

[hunt at redhat dot com]

Terminating stap before it finishes compiling results in 1 or 2 temporary
directories left in /tmp.

> ls -l /tmp/stap*
total 0

>  stap -c ls /data/hunt/stp/src/testsuite/systemtap.syscall/sys.stp
^C

> ls -l /tmp/stap*
/tmp/stapbzX4UB:
total 0

/tmp/stapFsFakj:
total 0

-- 
           Summary: translator not cleaning up temporary directories
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: hunt at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=5045

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/5045] translator not cleaning up temporary directories

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-02-08 16:03 -------
Fixing this would require a SIGINT/SIGTERM signal handler that sets a "exit-soon"
global, which in turn would have to be respected in the various long-winded loops
to exit early.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5045

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/5045] translator not cleaning up temporary directories

[hunt at redhat dot com]

------- Additional Comments From hunt at redhat dot com  2008-02-08 16:15 -------
(In reply to comment #1)
> Fixing this would require a SIGINT/SIGTERM signal handler that sets a "exit-soon"
> global, which in turn would have to be respected in the various long-winded loops
> to exit early.

What's wrong with using atexit()?


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5045

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/5045] translator not cleaning up temporary directories

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-02-08 16:24 -------
> What's wrong with using atexit()?

atexit() is documented as being called during normal termination,
not in response to signals.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5045

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/5045] translator not cleaning up temporary directories

[hunt at redhat dot com]

------- Additional Comments From hunt at redhat dot com  2008-02-08 17:02 -------
(In reply to comment #3)
> > What's wrong with using atexit()?
> 
> atexit() is documented as being called during normal termination,
> not in response to signals.

A quick test shows it seems to work in response to normal termination signals.
Even if it didn't, it just takes a few lines of code to set up a handler that
calls exit(). Why would you need an "exit-soon" global in a bunch of loops? None
of that happens right now, just the default action (termination) in response to
^C. All we want to do is add some cleanup before that happens.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5045

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/5045] translator not cleaning up temporary directories

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-02-08 17:16 -------
> A quick test shows it seems to work in response to normal termination signals.

What works?  atexit() hooks running during a termination signal?  Not in my
experiments.

> Even if it didn't, it just takes a few lines of code to set up a handler that
> calls exit().

But many functions cannot be legally called from signal handlers.
exit() specifically is not listed: see
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html

> Why would you need an "exit-soon" global in a bunch of loops? None
> of that happens right now, just the default action (termination) in response to
> ^C. All we want to do is add some cleanup before that happens.

Yes, but if we bother, let's do it cleanly.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5045

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/5045] translator not cleaning up temporary directories

[hunt at redhat dot com]

------- Additional Comments From hunt at redhat dot com  2008-02-08 17:43 -------
(In reply to comment #5)

> But many functions cannot be legally called from signal handlers.
> exit() specifically is not listed: see
> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html

_exit() is listed and the only difference between exit() and _exit() is that
exit() calls functions registered by atexit(). So as long as we keep that in
mind, we should be OK.  Or just do the cleanup (all necessary functions are in
the list) and call _exit(). 

There are, of course, other approaches. Your decision.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5045

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/5045] translator not cleaning up temporary directories

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-02-28 22:00 -------
patch committed; ^C now takes effect within a fraction of a second and
allows normal cleanup and program exit.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=5045

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.