core dump after alarm goes off

[The Pied Typer]

I have several related memory- and output-intensive Perl programs.
They all have a timeout option that uses the alarm function. The ALRM
handler goes into a temporary directory, unlinks all the files, removes
the directory, and exits.

These programs very often dump core after running the handler.
I know that they run the handler because the temporary directory
is gone afterwards. The handler is assigned by reference:

$SIG{ALRM} = $SIG{INT} = $SIG{TERM} = \&cleanup;

Has anybody seen anything like this? I suspect that the trouble
may occur when an output operation is interrupted.

-:-
I First he deals a deadly blow,
Then he staggers to and fro.
His behavior would be risible
If it only could be visible.

--The Roguelet's ABC

 

[A. Sinan Unur]

(e-mail address removed) (The Pied Typer) wrote in

I have several related memory- and output-intensive Perl programs.
They all have a timeout option that uses the alarm function. The ALRM
handler goes into a temporary directory, unlinks all the files,
removes the directory, and exits.

These programs very often dump core after running the handler.
I know that they run the handler because the temporary directory
is gone afterwards. The handler is assigned by reference:

$SIG{ALRM} = $SIG{INT} = $SIG{TERM} = \&cleanup;

Please post the shortest possible program that still exhibits this
behavior. Please read the posting guidelines for this group for tips on
how to post code. That will maximize your chances of getting useful
responses as opposed to a whole bunch of people wasting time trying to
guess exactly how you are doing things.

-:-

The correct sig separator is dash-dash-space on a line by themselves. I
see that you actually use that delimiter properly for your name and
email address, but by including a longish sigquote with this funny
separator, you are imposing on your readers the responsibility to snip
these irrelevant lines. Please consider using a shorter signature that
is properly separated from the body of your post.

Sinan

 

[Anno Siegel]

I have several related memory- and output-intensive Perl programs.
They all have a timeout option that uses the alarm function. The ALRM
handler goes into a temporary directory, unlinks all the files, removes
the directory, and exits.

These programs very often dump core after running the handler.
I know that they run the handler because the temporary directory
is gone afterwards. The handler is assigned by reference:

$SIG{ALRM} = $SIG{INT} = $SIG{TERM} = \&cleanup;

Has anybody seen anything like this? I suspect that the trouble
may occur when an output operation is interrupted.

There is always a potential problem with doing too much in a signal
handler, how much of a problem depends on the Perl version.

Assuming you want to do the cleanup after a normal end of the program too,
I'd put the cleanup routine in an END block. Then all your signal handlers
have to do is die, or even exit, so as to trigger the END block. An uncaught
signal, like any exception, bypasses END. Untested:

$SIG{ALRM} = $SIG{INT} = $SIG{TERM} = sub { exit };

# etc.

END { cleanup() }

I bet that will be less troublesome. If you want to bypass cleanup in
some cases, you can use a flag variable, or POSIX::_exit.

Anno

 

[xhoster]

I have several related memory- and output-intensive Perl programs.
They all have a timeout option that uses the alarm function. The ALRM
handler goes into a temporary directory, unlinks all the files, removes
the directory, and exits.

These programs very often dump core after running the handler.

What version of Perl?

perlipc:

Prior to Perl 5.7.3 it was necessary to do as little as you possibly
could in your handler; notice how all we do is set a global variable
and then raise an exception. That's because on most systems,
libraries are not re-entrant; particularly, memory allocation and
I/O routines are not. That meant that doing nearly anything in your
handler could in theory trigger a memory fault and subsequent core
dump - see "Deferred Signals" below.


Xho