Perl Packager - Free to wrong pool error

Discussion in 'Perl Misc' started by google@markginsburg.com, Mar 18, 2009.

  1. Guest

    > perl -v
    This is perl, v5.8.8 built for MSWin32-x86-multi-thread
    ....

    == Begin of test.pl ==
    use strict;
    use warnings;

    my $pid;

    LaunchHostname();

    print "waiting for child $pid to complete...\n";
    my $waitstat = waitpid($pid,0);
    print "waitpid returned $waitstat\n";
    exit;

    sub LaunchHostname {
    $pid = fork ();
    if (!defined($pid)) {
    die "Failed to fork: $!\n";
    }
    elsif ($pid == 0) {
    # This is the child
    exec('hostname.exe'); # LINE 22
    die "exec failed\n";
    }
    return;
    }
    == END of test.pl ==

    > perl test.pl

    waiting for child -3592 to complete...
    fileserver123
    waitpid returned -3592

    > pp -o test.exe test.pl


    > test.exe

    waiting for child -1600 to complete...
    fileserver123
    Free to wrong pool fac720 not 8367c0 at script/test.pl line 22.

    When I execute test.exe, the above error message is accompanied by a
    pop up indicating "test.exe has encountered a problem and needs to
    close. We are sorry for the inconvenience."

    When I do all the above on a system with perl v5.10.0 installed, I do
    not get the "Free to wrong pool" message but get a pop up that says:
    'The instruction at "0x2800cd70" referenced memory at "0x00000028".
    The memory could not be "read"'.

    Any ideas why I get these errors?
     
    , Mar 18, 2009
    #1
    1. Advertising

  2. Guest

    On Tue, 17 Mar 2009 17:32:22 -0700 (PDT), wrote:

    >> perl -v

    >This is perl, v5.8.8 built for MSWin32-x86-multi-thread
    >...
    >

    [snip]
    >Free to wrong pool fac720 not 8367c0 at script/test.pl line 22.
    >
    >When I execute test.exe, the above error message is accompanied by a
    >pop up indicating "test.exe has encountered a problem and needs to
    >close. We are sorry for the inconvenience."
    >
    >When I do all the above on a system with perl v5.10.0 installed, I do
    >not get the "Free to wrong pool" message but get a pop up that says:
    >'The instruction at "0x2800cd70" referenced memory at "0x00000028".
    >The memory could not be "read"'.
    >
    >Any ideas why I get these errors?


    I got that message when I tried out of range unicode chars in regular expression tests.
    But the windows MB says Perl encounterred an error and needs to close.
    I press OK and the command prompt returns.
    I do the very same command line again and get a different address, same result though.

    Looks like its not nice to exec a program from Perl that will crash.

    -sln
     
    , Mar 18, 2009
    #2
    1. Advertising

  3. Guest

    On Mar 17, 6:53 pm, Ben Morrow <> wrote:
    > Quoth :
    >
    >
    >
    > > > perl -v

    > > This is perl, v5.8.8 built for MSWin32-x86-multi-thread
    > > ...

    >
    > > == Begin of test.pl ==
    > > use strict;
    > > use warnings;

    >
    > > my $pid;

    >
    > > LaunchHostname();

    >
    > > print "waiting for child $pid to complete...\n";
    > > my $waitstat = waitpid($pid,0);
    > > print "waitpid returned $waitstat\n";
    > > exit;

    >
    > > sub LaunchHostname {
    > >     $pid = fork ();
    > >     if (!defined($pid)) {
    > >         die "Failed to fork: $!\n";
    > >     }
    > >     elsif ($pid == 0) {
    > >         # This is the child
    > >         exec('hostname.exe');  # LINE 22
    > >         die "exec failed\n";
    > >     }

    >
    > Since you're on Win32, is there a good reason for using fork/exec rather
    > than system(1, ...) or Win32::process? fork on Win32 is a rather
    > complicated emulation, and fork+exec ends up being a convoluted way of
    > calling spawnvp(3). Since the whole fork API is only present on Win32
    > for compatibility with Unix scripts, it's better to use the native
    > method.


    I was unaware that system() could be made to run asynchroneously.
    Thank you for the excellent suggestion, but I don't think it will work
    for my situation.

    With the fork/exec, I am starting a GUI application and then
    manipulating it in my perl code using Win32::GuiTest. This GUI
    application MUST be run from a specified directory, so in my actual
    perl program, I do a chdir() to that directory in the child process
    before the child calls exec() make the child perl process become the
    application. I don't think there is any way to do that using system
    (1,...).

    It is interesting to note that no errors occur when the perl program
    is run directly. The errors occur only when I run the executable I've
    created using pp. This makes me suspect that the problem may be
    related to something in PAR::packer.

    I was able to work around the problem (in an non-portable way) by
    using Win32::process::Create() instead of fork/exec. Fortunately for
    me, Win32::process::Create() takes the working directory as in input
    argument.

    > >     return;
    > > }
    > > == END of test.pl ==

    >
    > > > perl test.pl

    > > waiting for child -3592 to complete...
    > > fileserver123
    > > waitpid returned -3592

    >
    > > > pp -o test.exe test.pl

    >
    > > > test.exe

    > > waiting for child -1600 to complete...
    > > fileserver123
    > > Free to wrong pool fac720 not 8367c0 at script/test.pl line 22.

    >
    > 'Free to wrong pool' generally indicates a threading-related bug in
    > either perl itself or some XS module. Presumably you can get rid of this
    > be removing the fork, but there's still an underlying bug somewhere. A
    > lot of these 'Free to wrong pool' bugs were fixed in 5.10, and I expect
    > most of the fixes went into 5.8.9 as well.
    >
    > > When I execute test.exe, the above error message is accompanied by a
    > > pop up indicating "test.exe has encountered a problem and needs to
    > > close.  We are sorry for the inconvenience."

    >
    > > When I do all the above on a system with perl v5.10.0 installed, I do
    > > not get the "Free to wrong pool" message but get a pop up that says:
    > > 'The instruction at "0x2800cd70" referenced memory at "0x00000028".
    > > The memory could not be "read"'.

    >
    > > Any ideas why I get these errors?

    >
    > Not this one, sorry. Can you successfully build and execute anything
    > with pp? Can you reduce that test case at all and still provoke the bug?
    > Are you able to build a copy of perl with debugging symbols and get a
    > stack trace at the point of the crash?
    >
    > Ben
     
    , Mar 18, 2009
    #3
  4. wrote in news:0bd49123-0355-4fb7-a205-
    :

    > With the fork/exec, I am starting a GUI application and then
    > manipulating it in my perl code using Win32::GuiTest.


    ....

    > I was able to work around the problem (in an non-portable way) by
    > using Win32::process::Create() instead of fork/exec.


    I do not think portability to any other system than Win32 should be a
    concern in this case.

    Sinan
    --
    A. Sinan Unur <>
    (remove .invalid and reverse each component for email address)

    comp.lang.perl.misc guidelines on the WWW:
    http://www.rehabitation.com/clpmisc/
     
    A. Sinan Unur, Mar 18, 2009
    #4
  5. Guest

    On Wed, 18 Mar 2009 19:40:05 +0000, Ben Morrow <> wrote:

    >
    >Quoth :
    >> On Mar 17, 6:53 pm, Ben Morrow <> wrote:
    >> >
    >> > Since you're on Win32, is there a good reason for using fork/exec rather
    >> > than system(1, ...) or Win32::process? fork on Win32 is a rather
    >> > complicated emulation, and fork+exec ends up being a convoluted way of
    >> > calling spawnvp(3). Since the whole fork API is only present on Win32
    >> > for compatibility with Unix scripts, it's better to use the native
    >> > method.

    >>
    >> I was unaware that system() could be made to run asynchroneously.
    >> Thank you for the excellent suggestion, but I don't think it will work
    >> for my situation.
    >>
    >> With the fork/exec, I am starting a GUI application and then
    >> manipulating it in my perl code using Win32::GuiTest. This GUI
    >> application MUST be run from a specified directory, so in my actual
    >> perl program, I do a chdir() to that directory in the child process
    >> before the child calls exec() make the child perl process become the
    >> application. I don't think there is any way to do that using system
    >> (1,...).

    >
    >Well, the obvious way would be
    >
    > use Cwd qw/cwd/;
    >
    > my $oldcwd = cwd or die "can't find cwd: $!";
    > chdir "c:/wherever" or die "can't chdir to 'c:/wherever': $!";
    > system 1, "command";
    > chdir $oldcwd or die "can't chdir to '$oldcwd': $!";
    >
    >This of course assumes that you can determine your current directory and
    >chdir back into it, so if Win32 supports fchdir(2) something like
    >
    > opendir my $OLDCWD, "." or die "can't opendir '.': $!";
    > chdir "c:/wherever" or die "...";
    > system 1, "command";
    > chdir $OLDCWD;
    >
    >might be safer (substitute File::Spec->curdir if you like). You can
    >check if you have fchdir(2) with
    >
    > perl -V:d_fchdir
    >
    >or
    >
    > use Config;
    >
    > if ($Config{d_fchdir} eq "define") {
    > ...
    > }
    >
    >> It is interesting to note that no errors occur when the perl program
    >> is run directly. The errors occur only when I run the executable I've
    >> created using pp. This makes me suspect that the problem may be
    >> related to something in PAR::packer.

    >
    >Yes, me too. I have had numerous problems with pp on Win32 in the past;
    >the peculiarities of perl and of Win32's dll model combine to mean PAR
    >has to do some very strange things to get the program to work.
    >Apparently they don't always work successfully.
    >
    >> I was able to work around the problem (in an non-portable way) by
    >> using Win32::process::Create() instead of fork/exec. Fortunately for
    >> me, Win32::process::Create() takes the working directory as in input
    >> argument.

    >
    >Yes, whatever you do it will end up calling CreateProcess(2) eventually,
    >so you might as well call it directly.
    >
    >Ben


    Which variable is '2'?

    BOOL CreateProcess(
    LPCTSTR lpApplicationName,
    LPTSTR lpCommandLine,
    LPSECURITY_ATTRIBUTES lpProcessAttributes,
    LPSECURITY_ATTRIBUTES lpThreadAttributes,
    BOOL bInheritHandles,
    DWORD dwCreationFlags,
    LPVOID lpEnvironment,
    LPCTSTR lpCurrentDirectory,
    LPSTARTUPINFO lpStartupInfo,
    LPPROCESS_INFORMATION lpProcessInformation
    );

    -sln
     
    , Mar 18, 2009
    #5
  6. Tim McDaniel Guest

    In article <>,
    <> wrote:
    >On Mar 17, 6:53 pm, Ben Morrow <> wrote:
    >> Since you're on Win32, is there a good reason for using fork/exec rather
    >> than system(1, ...) or Win32::process?

    ....
    >
    >I was unaware that system() could be made to run asynchroneously.


    I'd never heard of it either. I Googled and found
    <http://www.mail-archive.com//msg35810.html>
    explaining things.

    It's not documented in "perlfunc system" but in "man perlport". The
    text (the trailing "(Win32)" apparently means "this paragraph applies
    to Windows 32-bit"):

    As an optimization, may not call the command shell specified in
    $ENV{PERL5SHELL}. "system(1, @args)" spawns an external process
    and immediately returns its process designator, without waiting
    for it to terminate. Return value may be used subsequently in
    "wait" or "waitpid". Failure to spawn() a subprocess is indicated
    by setting $? to "255 << 8". $? is set in a way compatible with
    Unix (i.e. the exitstatus of the subprocess is obtained by "$? >>
    8", as described in the documentation). (Win32)

    The Jan Dubois, in that note above, also wrote "

    > One thing that may not be obvious from the documentation is that
    > Perl keeps track of the process ids returned by system(1, ...), and
    > the call will fail once you have created more than 63 processes.
    >
    > Check here for a "workaround" to make sure you at least reclaim
    > handles of processes no longer running:
    >
    > http://aspn.activestate.com/ASPN/Mail/Message/pdk/3122771
    >
    > You will still be limited to about 63 concurrent processes.


    I haven't looked further for a few minutes, but I found no other
    gotchas.

    --
    Tim McDaniel,
     
    Tim McDaniel, Mar 20, 2009
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gavin Williams
    Replies:
    0
    Views:
    3,721
    Gavin Williams
    Jul 22, 2004
  2. george
    Replies:
    0
    Views:
    1,195
    george
    Aug 29, 2008
  3. Rick Lawson
    Replies:
    8
    Views:
    859
    Graham Dumpleton
    Jul 17, 2009
  4. Replies:
    1
    Views:
    208
    greenrob
    Jul 14, 2006
  5. Replies:
    4
    Views:
    214
Loading...

Share This Page