«

> 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?

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

On Mar 17, 6:53*pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth goo...@markginsburg.com:
>
>
>
> > > 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:rocess? 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:acker.

I was able to work around the problem (in an non-portable way) by
using Win32:rocess::Create() instead of fork/exec. Fortunately for
me, Win32:rocess::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

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:rocess::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/

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

>
>Quoth :
>> On Mar 17, 6:53*pm, Ben Morrow <b...@morrow.me.uk> wrote:
>> >
>> > Since you're on Win32, is there a good reason for using fork/exec rather
>> > than system(1, ...) or Win32:rocess? 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:acker.
>
>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:rocess::Create() instead of fork/exec. Fortunately for
>> me, Win32:rocess::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

In article <0bd49123-0355-4fb7-a205->,
<> wrote:
>On Mar 17, 6:53*pm, Ben Morrow <b...@morrow.me.uk> wrote:
>> Since you're on Win32, is there a good reason for using fork/exec rather
>> than system(1, ...) or Win32:rocess?
....
>
>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/perl-win32-/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/Mai...ge/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,