One thing that sometimes causes this error are: Buggy XS modules. Another is when you try to do too much stuff in a signal handler function. Do you have any signal handlers in your program?

Ok, i'll try narrowing code, and checking if it still crashes :)

But still have a question: is it possible that buggy module can cause "my" error in the place of code where it is not used?

And I don't do much with signal handlers in my code so I think it's not the problem (but I'll try to check this of course!)

Thanks.

-- 
Daniellek
[download]

daniellek says:

<blcokquote> > is it possible that buggy module can cause
> "my" error in the place of code where it is not used?

Yes, that's exactly why it is so hard to track down this sort of bug. Memory is corrupted in one place and then the probably does not manifest until later on.

When perl then went to DESTROY these objects when they went out of scope, it got very unhappy about attempting to free ( the embedded object ) an unreferenced scalar ( since the referencing object was already gone ).

I am not claiming this isn't a bug, nor am I claiming this is your problem. I am merely offering my past experience hoping it may help.

Mik
mikfire

I was getting this bug today and none of the pages I read helped so I figured I should post now that I figured out the problem. All pages I read indicate it's probably a perl bug itself. But for me it was due to having a foreach loop like this:

foreach $key (keys %hash) {


}

with another foreach loop inside using the same variable name and same hash

foreach $key (keys %hash) {
   foreach $key (keys %hash) {


   }
}


Incidentally, this only caused the problem in strict mode. I'm not saying this simple loop would replicate the problem, I got it down to about 20 lines and still throwing the error. But if you're getting this error message, look for a nested thing like that, it might be what's causing it. Perl should maybe throw a warning when a loops are nested like that with the same variables, because otherwie it was pretty hard to track down in my 1000 line program, I had to remove piece by piece until it became evident.

open (LISTA, "find $folder -type f|")
  or die "Cannot find '$folder': $!";
[download]

And another thing, you are likely littering the process table with zombies. This may well be the cause of your loop crashing. You can either set a child handler, or you can start calling wait or waitpid to let your children exit. (If this guess is right then the error check should have noticed and pointed you in the right direction.)

UPDATE
I think I am wrong about the zombie guess. As mentioned below I suspect either memory corruption or a Perl bug. Using backticks to collect output may fix the program, but the bug should still be tracked down and reported.

I don't use 'die', because this is not problem with opening "find"... I tried it some time ago, but script didn't die and "unreferenced..." where still there.

I don't know if I understand second part of Your answer, but i need this script to be multithreaded...

Thanks in advance for your patience :)

-- 
Daniellek
[download]

Please use die. Please, please, please. Even if it is not the problem this time, it is a really bad idea to leave production code sitting around without error checks left in. The majority of time and energy is spent on maintaining code, and error checks make a massive difference in either narrowing down what the problem is or what it isn't.

As for the second part...(reads)...oops. I was giving advice based on my experiences with IPC::Open3, apparently on a straight piped open Perl does wait for you. In case you need to know that, when a child process is created and tries to die, it cannot finish dying until it tells its parent what its return status is. A process can wait in this last stage of death forever, and a process in that state is called a zombie. So if you spawn lots of children, then you have to check for them from time to time to avoid zombies.

Still for your use, consider using `` to run the system commands and collect output. Less code, and the error checks are done for you.

That may fix the problem, but still glancing in perldiag I see that your warning is supposed to indicate either a bug at the C level (in Perl or in an XS module) or else memory corruption. If you have no C modules you are going to and can reproduce the problem on another box, it is a Perl bug and you should use the perlbug utility to report it. First try to whittle it down to the smallest loop that you can which produces the problem. Then report it.