Closed p5pRT closed 21 years ago
Running the following test script causes perl to crash. You may need to run the script several times before seeing the problem. (The script spawns a child process that does nothing but write to an array. The parent signals the child periodically.)
#!/usr/local/bin/perl -w
use strict;
use constant CHUNK_SIZE => 128; use constant ARRAY_SIZE => 1_000_000;
$| = 1;
if(my $pid = fork) {
# parent signals periodically
while(1) {
select undef\, undef\, undef\, 0.1;
kill(ALRM => $pid) == 1 or die "cannot signal: $!";
print ".";
}
} else {
# is kid up?
unless(defined $pid) { die "cannot fork: $!"; }
# initialize array (by using last element)
my @data;
$data[ARRAY_SIZE] = 1;
# state of the process (number of alarms received)
my $state = 0;
$SIG{ALRM} = sub { $state++ };
# run the test
while(1) {
# calculate new position for this iteration
my $pos = int rand ARRAY_SIZE;
# write a chunk to a random position
@data[$pos..$pos+CHUNK_SIZE] = (1) x CHUNK_SIZE;
}
}
Execution of this script results in the following output:
[sub: ~/thesis/bin] short ......................perl in malloc(): warning: recursive call. Out of memory! ....perl in malloc(): warning: recursive call. Out of memory! perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl.perl in malloc(): warning: recursive call. Out of memory! perl in free(): warning: recursive call. cannot signal: No such process at short line 14. Exit 3
Please let me know if I can provide any other information to help track this bug down.
Lars Eggert writes:
Running the following test script causes perl to crash. You may need to run the script several times before seeing the problem. (The script spawns a child process that does nothing but write to an array. The parent signals the child periodically.)
Signals and Perl do not mix. Please do not use signals if a segfault is not a desirable form of output.
$SIG{ALRM} = sub { $state++ };
One should not do anything as bad as that in a sighandler. What is the failure rate you see? You may get slightly better rate (3% in my tests) with something like
$SIG{ALRM} = sub { ++$state ; return };
and preallocating
$state = 0;
Ilya
Ilya\,
thanks for the quick response.
Signals and Perl do not mix. Please do not use signals if a segfault is not a desirable form of output.
Never? After reading perlipc I was under the impression that using signals was okay if you keep your handlers simple. I may have to use to another form of IPC if signals cannot be made safe.
Lars ____________________________________________________________________________ Lars Eggert \larse@​isi\.edu Information Sciences Institute http://www.isi.edu/~larse/ University of Southern California
On Mon\, Jan 24\, 2000 at 09:53:27PM -0800\, Lars Eggert wrote:
Signals and Perl do not mix. Please do not use signals if a segfault is not a desirable form of output.
Never?
Never. Well\, I did not try XSUB signal handlers\, but if it is a Perl subroutine\, then the harm may be already done *before* the subroutine starts.
Ilya
On Mon\, 24 Jan 2000\, Lars Eggert wrote:
Ilya\,
thanks for the quick response.
Signals and Perl do not mix. Please do not use signals if a segfault is not a desirable form of output.
Never? After reading perlipc I was under the impression that using signals was okay if you keep your handlers simple. I may have to use to another form of IPC if signals cannot be made safe.
Our malloc can't be used in a signal handler.
Lars ____________________________________________________________________________ Lars Eggert \larse@​isi\.edu Information Sciences Institute http://www.isi.edu/~larse/ University of Southern California
To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Chuck Robey | Interests include C & Java programming\, FreeBSD\, chuckr@picnic.mat.net | electronics\, communications\, and signal processing.
New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary.
On Tue\, Jan 25\, 2000 at 02:44:05PM -0500\, Chuck Robey wrote:
On Mon\, 24 Jan 2000\, Lars Eggert wrote:
Ilya\,
thanks for the quick response.
Signals and Perl do not mix. Please do not use signals if a segfault is not a desirable form of output.
Never? After reading perlipc I was under the impression that using signals was okay if you keep your handlers simple. I may have to use to another form of IPC if signals cannot be made safe.
Our malloc can't be used in a signal handler.
One can write a signal handler in such a way that no mallocs are going to be called (see my example). But this would not help: segfaults will happen anyway.
Ilya
On Tue\, 25 Jan 2000\, Ilya Zakharevich wrote:
On Tue\, Jan 25\, 2000 at 02:44:05PM -0500\, Chuck Robey wrote:
On Mon\, 24 Jan 2000\, Lars Eggert wrote:
Ilya\,
thanks for the quick response.
Signals and Perl do not mix. Please do not use signals if a segfault is not a desirable form of output.
Never? After reading perlipc I was under the impression that using signals was okay if you keep your handlers simple. I may have to use to another form of IPC if signals cannot be made safe.
Our malloc can't be used in a signal handler.
One can write a signal handler in such a way that no mallocs are going to be called (see my example). But this would not help: segfaults will happen anyway.
Do you know for a fact that perl\, in the signal handler code\, is not calling malloc?
Chuck Robey | Interests include C & Java programming\, FreeBSD\, chuckr@picnic.mat.net | electronics\, communications\, and signal processing.
New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary.
On Tue\, Jan 25\, 2000 at 05:25:40PM -0500\, Chuck Robey wrote:
Do you know for a fact that perl\, in the signal handler code\, is not calling malloc?
$a = 0; # Prealloc the numeric slot; $SIG{FOO} = sub { ++$a; return };
will not call malloc()/free()/realloc(). [At least around 5.004].
But this is easy to check. Before the programs starts to recieve signals\, let it make call some obscure function. I usually do
binmode STDERR;
or some such. Set breakpoint in Perl_pp_binmode. When hit (this way all the hard memory-allocation part is already done\, so you will not get false positives)\, set breakpoints in malloc\, free\, realloc\, and Perl_sighandler. Watch your results (continue after each breakpoint).
Ilya
(I'm just reviewing old Perl bug reports).
Since Perl 5.8.0\, sygnal handling has become "safe"\, ie the C-level sigbnal handler just sets a flag then return; and Perl doesn't call the Perl-level signal handler until after the current Perl op has finished.
So presumably your problem is now resolved.
Regards\,
Dave M.
@iabyn - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#2028 (status was 'resolved')
Searchable as RT2028$