When you fork in AS perl under win32 (I think cygwin builds work differently), you aren't creating another process, You are instantiating another interpreter on a new thread. That's the tie-in to iThreads.

The "Free to wrong pool" indicates that a piece of memory allocated by one instance of the interpreter has come up for destruction by a different interpreter.

Quite how this is alleviated by the presence of a commented out line that references no variables I can't imagine, but as a fix, you might try requireing Win32::MMF::Shareable within each branch of the if( fork ) { statement.

I'm hazarding a guess that some load-time (BEGIN|INIT|CHECK} code is allocating a variable in the parent thread and the child thread is inheriting it and trying to free it.

This is mostly guesswork, but it would be worth a try.

Thanks for the suggestion BrowserUk, I have reviewed the module code for Win32::MMF::Shareable, and after extensive debugging, I (think that I) have discoverred that the module might not be thread safe. I am doing some experiments at the moment to see if I could have independend sets of data both child and parents so they don't interfere with each other, as currently the child and parent share the same set of global data.

I tried your suggestion: I removed the use Win32::MMF::Shareable line at the start, which gets loaded at compile time, and then added require in each parent and child processes after the fork. The problem some how has gone away. The following is the test code I used:


#!C:/Perl/bin/perl -w
use strict;
use Data::Dumper;

if( fork )
{
  require Win32::MMF::Shareable;
  my $ns = tie( my %share, 'Win32::MMF::Shareable', 'share' ) || die;
  sleep(1);
  $share{parent} = 1;
  print Dumper(\%share);
}
else
{
  require Win32::MMF::Shareable;
  my $ns = tie( my %share, 'Win32::MMF::Shareable', 'share' ) || die;
  $share{child} = 1;
}
[download]


Is this because the require is executed at run-time, which causes two different copy of Storable to be loaded at run-time, which in turn gets freed properly in their own instances?

And thanks again!

Is this because the require is executed at run-time, which causes two different copy of Storable to be loaded at run-time, which in turn gets freed properly in their own instances?

Yes. YW :)

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Timing (and a little luck) are everything!

The crash is at 77C43038 in msvcrt.dll, which is called from Storable.dll!00335423() . Hopefully, that will clue the author of the dll (Roger?).

Thanks NetWallah for the debug information, now I have something to start with.

I changed the tie() variable to a simple scalar, so that it will be go through shareable, and tested again, the following code, almost exactly the same as before, works with no problems. So I guess the problem is really in Shareable.


#!C:/Perl/bin/perl -w
use strict;
use Win32::MMF;
use Win32::MMF::Shareable;

if( fork )
{
  my $ns = tie( my $share, 'Win32::MMF::Shareable', 'share' ) || die;
  sleep(1);
  $share = 'PARENT';
}
else
{
  my $ns = tie( my $share, 'Win32::MMF::Shareable', 'share' ) || die;
  $share = 'CHILD';
}
[download]


Now the question comes down to why Storable is causing Perl to crash? Is the Storable module thread safe? Is there a thread safe alternative?

Update:
I have tried BrowserUk's suggestion and the problem seems to have gone away. I am currently investigating on why having require in each process after fork cures the problem.

As a first try, check to see if B::Deparse results in the same code with and without the comment - having said that, I'm not hopeful that will reveal much, but it will discount one possible cause.

The whole fact that "fork doesn't really fork" should be enough to scare people away from doing it...of course, naming the method fork() doesn't seem to advertise that fact very well.

Since this app is pure Win32 (using the Win32 memory mapped file stuff), it makes sense to remove the forking altogether...after all, forking on Win32 is pretty much a hack...could it be moved over a threaded model, with locks (if needed) where needed?

The require trick mentioned above still doesn't solve the following scenario:

use strict;
require Win32::MMF::Shareable;
$|++;

tie( my $share, 'Win32::MMF::Shareable', 'share' ) || die;
$share = 'foo';

# do some unrelated forking with $share in scope
unless( fork ) { exit 0 }

# make sure child exits before continuing
sleep 1;

# set/get crashes
print "----before\n";
$share = 'bar';
my $temp = $share;
print "----after\n";

__END__

----before
[download]

use japh; print;
[download]

Hi xiper, as BrowserUk has suggested earlier, there is a problem with forking under Windows. The cure is to create two separate instances of Shareable, one in child and one in parent. So the require should be after the fork. I modified the code to below and it ran without problems.


use strict;
$|++;

# do some unrelated forking with $share in scope
unless( fork ) { exit 0 }

require Win32::MMF::Shareable;
tie( my $share, 'Win32::MMF::Shareable', 'share' ) || die;
$share = 'foo';

# make sure child exits before continuing
sleep 1;

# set/get crashes
print "----before\n";
$share = 'bar';
my $temp = $share;
print "----after\n";
[download]

Yes, but a solution that changes the logic of a program isn't practical. You're effectivly saying that "you can't fork with a tied variable in scope" - even if the child has nothing to do with the tied variable. My point was it isn't always possible (nor should it be) to redesign a program around this 'solution'.

- ><iper

use japh; print;
[download]