1. I know, in old versions of Perl, including 5.6.1, there were problems with signal+memory access.
   
   For example, I have a test case, in which I have one parent process and one forked child process. The parent process keep sending signals to the child, and the child just write to some random position in a big sparse array, each time it receives signal.
   
   In the past, when I tested it with 5.6.1, I first saw "perl in free(): warning: recursive call" repeating several times, then came this "perl in malloc(): warning: recursive call", and crashed.
   
   I just tested it again with 5.8.0, it appeared to have been fixed already.
   
   SO UPGRADE TO 5.8.0
2. So all the memory problems are gone? NO, and this probably will never happen, although we will see Perl become more and more stable, and less problems with memory access. Remember the purpose of testing is not to prove the application is 100% correct, but to find bugs. Especially with any c based application, memory related problems are the most naughty ones.
   
   I also tested the following case with 5.8.0 + win32, and it still crashed, complaining "free to wrong pool".

   my %hash = map {$_,"Merry Christmas!"} (1..100);
   
   foreach my $value (values %hash) {
      crash_it(\%hash, $value);
   }
   
   sub crash_it {
      my ($hash, $value) = @_;
      delete $hash->{1};
   }
   [download]

"I first saw "perl in free(): warning: recursive call" repeating several times, then came this "perl in malloc(): warning: recursive call", and crash"
I have exactly this stuff.

"SO UPGRADE TO 5.8.0"
I'm using standart FreeBSD4.7 perl. It has 5.005 version number. I always wanted to know: what is the 5.00x branch and the 5.x.x branch? Is 5.005 === 5.8.0?

Nope 5.005 < 5.8.0

For one big difference. 5.8 has threads and 5.005 does not.

GOK but this is how the version numbering goes with Perl 5

5.004 == 5.4
5.005 == 5.5
5.6   == 5.6 (5.006)
5.8   == 5.8 (5.008)
[download]

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

As a general rule, you should do as little as possible in a signal handler. Typical actions would be to set a flag (which will be detected in the mainline code), or to increment a semaphore (to wake up a thread -- to continue processing). --Dave

So there is neither any magic "i want safe signals" option no newest signals safe version of perl?
I didn't post any code because i think this is a general problem: simple daemon that updates mysql db once per 10 sec using alarm signal.

I didn't post any code because i think this is a general problem: simple daemon that updates mysql db once per 10 sec using alarm signal.

That's like saying "I didn't post any code, because it's just a little CGI that does some stuff and prints HTML" ... the devil is in the details.

As a general rule: If you have a question about why some code doesn't do what you expect. Post the code (or the smallest sample program that demonstrates the problem).

In situations where your question concerns an err msg you are getting, the "general rule" becomes the golden rule: If you are getting an eror, from code you think should work, post a sample program that generates the error, and the exact text of the error, along with your question.