You are going to have to supply some additional context (ie. code:) if you are going to get further help with this.

The following snippet taken almost verbatim from the Net::Ping pod seems to work ok under AS 5.8 on my NT4/sp6a system. Perhaps you could try it on your W2k system and see what the result is.

#! perl -slw
use strict;
use Net::Ping;
use Time::HiRes;

my $host = 'bbc.co.uk';
my $p = Net::Ping->new('tcp');
$p->{portnum} = 80;
$p->hires();
my ($ret, $duration, $ip) = $p->ping($host);
printf("$ret:$host [ip: $ip] is alive (packet return time: %.2f ms)\n"
+, 1000 * $duration);
$p->close();
__END__
D:\Perl\test>245918
About to fork

1:bbc.co.uk [ip: 132.185.132.204] is alive (packet return time: 4907.0
+6 ms)

D:\Perl\test>
[download]

Note: The 'About to fork' is a line I added to my copy of Net::Ping.pm just before the line that is giving your error to ensure that I am exercising the same code path as you.

Bizarre SvType [187] at
[download]

187 is 0xBB which immediately makes me think of Microsoft pre-initializing memory to such things (I usually see 0xCC but have seen other values). I'll see if I can dig up information on what these values mean.

But this at least looks like Perl is either failing to initialize some memory, using a pointer to some memory that has been free()d, or using a corrupted pointer.

And that doesn't surprise me since fork emulation in Win32 Perl has always been pretty buggy, even after several releases (and several claims that it should be stable). I've heard claims that Perl v5.8 should make fork emulation less buggy, but it is using a brand new scheme (which does hold promise for being more stable) and so, being new, I'd be a bit surprised if it weren't still at least a little buggy.

I avoid using fork in Win32 Perl. You can probably avoid it in this situation as well, though it can be a challenge. I've covered some aspects of avoiding fork ((tye)Re: How to multiprocess in Win32?) and of pinging (Net::Ping, the mini series).

Update: I managed to find the following special values:

0xCC

uninitialized local variables (if compiled with /GZ)

0xFD

no-man's land (area around a malloc'd block)

0xDD

freed blocks

0xCD

new objects

BTW, SV types go from 0x00 through 0x0F. 4 bits of the SV type are never used.

fork() emulation in 5.8 is actually using the same scheme as in 5.6 (ithreads). The ithread code in 5.8 is indeed improved over 5.6, especially in the area of regex concurrency problems. But a lot of XS code doesn't really know about ithreads, and as long as modules are not thread-safe at the XS level, there is not much you can do at the Perl level.

Note that I'm not saying that I think ithreads is working flawless in 5.8; I think it should still be considered experimental.

Thanks for the information.

I have determined that the cause of the crash is related to using Win32::OLE in the same script. This script crashes too:

use Net::Ping;
use Win32::OLE; # or use Win32::OLE::Variant;
$p = Net::Ping->new();
print $p->ping($hostname);
[download]

For the immediate period, I have found that by changing the protocol to "icmp", I don't get the error.
Setting the protocol to "external" doesn't cause the crash either, but occasionally returns false even for hosts that are alive.