Re: $^E bug and perl 5.8.0
On Wed, Nov 19, 2003 at 11:49:14AM -0500, Dan Sugalski wrote: I think I'll take steps to make this less likely for Parrot, though I'm not sure there's truly any good way to get around it anywhere but in the actual application code. This issue has come on p5p before (a few years ago) and the consensus, as I recall, was that $! shouldn't be tied directy to errno but should be set explicitly by the internals whenever a pp op was about to report an error to the application code. Tim.
Re: $^E bug and perl 5.8.0
For what it's worth, I've been trying out 5.8.2, and I get the same value for 5.8.1-RC3 and 5.8.1 final, both the same negative numbers. I am building with the same options as the Panther version (darwin-thread-multi-2level); are you? -- Edward Moy Apple (This message is from me as a reader of this list, and not a statement from Apple.) On Nov 18, 2003, at 5:13 PM, Chris Nandor wrote: $ perl5.8.0 -le '$! = -1728; print $^E+0 for 0,1' -1728 22 This appears to be fixed in perl5.8.1, in the RC3 version that ships with Panther: $ perl5.8.1 -le '$! = -1728; print $^E+0 for 0,1' -1728 -1728 Bu in a perl 5.8.1 RC1 I built myself: $ perl5.8.1 -le '$! = -1728; print $^E+0 for 0,1' -1728 22 And in a fresh build of perl 5.8.2: $ perl5.8.2 -le '$! = -1728; print $^E+0 for 0,1' -1728 22 Is this a known issue? Anyone know if it's been reported, or what the problem might be? -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: $^E bug and perl 5.8.0
At 1:05 am -0800 19/11/03, [EMAIL PROTECTED] wrote: For what it's worth, I've been trying out 5.8.2, and I get the same value for 5.8.1-RC3 and 5.8.1 final, both the same negative numbers. I am building with the same options as the Panther version (darwin-thread-multi-2level); are you? FWIW I get the same results as Chris with 5.8.2 and have used the build configuration as Apple recommended for _Jaguar_ and 5.8. So maybe this is the problem in my case at least -- might explain my problems with with Tk also perhaps. Can you please post the parameters I should use with Configure. JD
Re: $^E bug and perl 5.8.0
At 9:51 + 2003.11.19, John Delacour wrote: At 1:05 am -0800 19/11/03, [EMAIL PROTECTED] wrote: For what it's worth, I've been trying out 5.8.2, and I get the same value for 5.8.1-RC3 and 5.8.1 final, both the same negative numbers. I am building with the same options as the Panther version (darwin-thread-multi-2level); are you? FWIW I get the same results as Chris with 5.8.2 and have used the build configuration as Apple recommended for _Jaguar_ and 5.8. So maybe this is the problem in my case at least -- might explain my problems with with Tk also perhaps. Are the problems you are having with Tk similar? At least someone else has the problem, so I know I am not crazy (well, at least, that this is not evidence of it). I'm doing some more test builds now. On the dual G5, they go by pretty quickly. :) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: $^E bug and perl 5.8.0
(For the porters: the bug is that this: % perl -le '$^E = -1728; print $^E+0 for 0,1' Should return this: -1728 -1728 But in some cases, returns this: -1728 22 Odd.) At 1:05 -0800 2003.11.19, [EMAIL PROTECTED] wrote: For what it's worth, I've been trying out 5.8.2, and I get the same value for 5.8.1-RC3 and 5.8.1 final, both the same negative numbers. I am building with the same options as the Panther version (darwin-thread-multi-2level); are you? I am building with the defaults, not with anything in particular. [Slash:local/src/perl-5.8.2] apple% ./perl -Ilib -V Summary of my perl5 (revision 5.0 version 8 subversion 2) configuration: Platform: osname=darwin, osvers=7.0.0, archname=darwin-2level uname='darwin slash.local 7.0.0 darwin kernel version 7.0.0: wed sep 24 15:48:39 pdt 2003; root:xnuxnu-517.obj~1release_ppc power macintosh powerpc ' config_args='-des' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing', optimize='-Os', cppflags='-no-cpp-precomp -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing' ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build 1495)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags ='' libpth=/usr/lib libs=-ldbm -ldl -lm -lc perllibs=-ldl -lm -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under darwin Compiled at Nov 19 2003 06:36:12 @INC: lib /usr/local/lib/perl5/5.8.2/darwin-2level /usr/local/lib/perl5/5.8.2 /usr/local/lib/perl5/site_perl/5.8.2/darwin-2level /usr/local/lib/perl5/site_perl/5.8.2 /usr/local/lib/perl5/site_perl . Differences I see off the bat: usethreads useithreads usemultiplicity -g for ccflags ld (though mine is right, RC3's is wrong, I believe) useshrplib (though I did it both ways, with and without) Using your exact config_args from RC3, I get the proper values. Lessee ... I know it is not -g or useshrplib. Trying with only '-ds -e -Duseithreads': yep, now I get the proper values. But I don't want threads. But trying to dig deeper, I'll try enabling usemultiplicity on its own: nope, that gives me the same bug. So, it looks like if I turn on ithreads, it is fine. If not, it isn't. I have no idea WHY it would be the case, and I really wish it weren't, as I really don't want to have threads, if I can avoid it (unless I am just being ignorant: last I heard, a threaded perl still had trouble with mod_perl). But there's gotta be a bug here, regardless. Anyone, a little help? :) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: $^E bug and perl 5.8.0
At 16:39 +0100 2003.11.19, Rafael Garcia-Suarez wrote: What does perl -le 'print $!=22' on your system ? 22. Can you reproduce this bug with $! in place of $^E ? I tested, but neglected to mention. No, $! works fine (unless observing $^E already changed the value of $!): $ perl -le '$^E = -1728; print $!+0 for 0,1; print $^E+0 for 0,1' -1728 -1728 -1728 22 $ perl -le '$^E = -1728; print $^E+0 for 0,1; print $!+0 for 0,1' -1728 22 22 22 Changing the initial $^E to $! makes absolutely no difference: $ perl -le '$! = -1728; print $!+0 for 0,1; print $^E+0 for 0,1' -1728 -1728 -1728 22 $ perl -le '$! = -1728; print $^E+0 for 0,1; print $!+0 for 0,1' -1728 22 22 22 -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: $^E bug and perl 5.8.0
On Wed, 19 Nov 2003, Chris Nandor wrote: $ perl -le '$^E = -1728; print $^E+0 for 0,1; print $!+0 for 0,1' -1728 22 22 22 Given that on Unix systems $^E and $! are identical, and that $! is directly tied to errno, this certainly isn't surprising. Anything that afects errno (like, say, IO) may then affect $! and $^E identically.(And $!/$^E non-indentically on systems where they're separate) Basically you're using a variable that can be affected by external things in a way that pretty much guarantees that external things will be happening. That it changes isn't much of a surprise. ($!/$^E may get modified by some signal handlers too, depending on what you do, so there's not even any guarantee that $^E = 42; $^E++; will end up with $^E set to 43. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: $^E bug and perl 5.8.0
At 10:59 -0500 2003.11.19, Dan Sugalski wrote: On Wed, 19 Nov 2003, Chris Nandor wrote: $ perl -le '$^E = -1728; print $^E+0 for 0,1; print $!+0 for 0,1' -1728 22 22 22 Given that on Unix systems $^E and $! are identical, and that $! is directly tied to errno, this certainly isn't surprising. Anything that afects errno (like, say, IO) may then affect $! and $^E identically.(And $!/$^E non-indentically on systems where they're separate) Basically you're using a variable that can be affected by external things in a way that pretty much guarantees that external things will be happening. That it changes isn't much of a surprise. ($!/$^E may get modified by some signal handlers too, depending on what you do, so there's not even any guarantee that $^E = 42; $^E++; will end up with $^E set to 43. It should not change its value merely by accessing its value. It's never done that in previous versions of perl, and shouldn't do it now. If you're saying that the value of $! changing after $^E changes is not surprising, yes, I agree. But the value of $^E changing is very surprising, and wrong. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: $^E bug and perl 5.8.0
On Wed, 19 Nov 2003, Rafael Garcia-Suarez wrote: Dan Sugalski wrote: Basically you're using a variable that can be affected by external things in a way that pretty much guarantees that external things will be happening. That it changes isn't much of a surprise. ($!/$^E may get modified by some signal handlers too, depending on what you do, so there's not even any guarantee that $^E = 42; $^E++; will end up with $^E set to 43. Using the Mac OS X equivalent of truss/strace might help to find out why errno changes there. My bet would be that the print triggers an errno update, which strikes me as perfectly reasonable. A syscall could be the result there, and syscalls can twiddle errno if they want to. A bit excessive if nothing goes wrong, perhaps, but not out of order. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: $^E bug and perl 5.8.0
At 16:50 +0100 2003.11.19, Rafael Garcia-Suarez wrote:
Chris Nandor wrote:
At 16:39 +0100 2003.11.19, Rafael Garcia-Suarez wrote:
What does
perl -le 'print $!=22'
on your system ?
22.
Hmm, weird -- on my Linux 2.2 it prints correctly Invalid argument.
I wanted to know what was this errno corresponding to.
Ah.
[EMAIL PROTECTED] pudge]$ perl -le 'print $!=22'
Invalid argument
Try this naive patch :
--- mg.c.orig Wed Nov 19 16:41:47 2003
+++ mg.c Wed Nov 19 16:44:14 2003
@@ -623,8 +623,12 @@ Perl_magic_get(pTHX_ SV *sv, MAGIC *mg)
SetLastError(dwErr);
}
#else
- sv_setnv(sv, (NV)errno);
- sv_setpv(sv, errno ? Strerror(errno) : );
+ {
+ int saveerrno = errno;
+ sv_setnv(sv, (NV)errno);
+ sv_setpv(sv, errno ? Strerror(errno) : );
+ errno = saveerrno;
+ }
#endif
#endif
#endif
Heh, when I do that, I get:
$ perl -le '$^E=-1728; print $^E+0 for 0,1'
22
22
So I don't even get the correct value the *first* time. :)
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: $^E bug and perl 5.8.0
On Wed, 19 Nov 2003, Chris Nandor wrote: At 10:59 -0500 2003.11.19, Dan Sugalski wrote: On Wed, 19 Nov 2003, Chris Nandor wrote: $ perl -le '$^E = -1728; print $^E+0 for 0,1; print $!+0 for 0,1' -1728 22 22 22 Given that on Unix systems $^E and $! are identical, and that $! is directly tied to errno, this certainly isn't surprising. Anything that afects errno (like, say, IO) may then affect $! and $^E identically.(And $!/$^E non-indentically on systems where they're separate) Basically you're using a variable that can be affected by external things in a way that pretty much guarantees that external things will be happening. That it changes isn't much of a surprise. ($!/$^E may get modified by some signal handlers too, depending on what you do, so there's not even any guarantee that $^E = 42; $^E++; will end up with $^E set to 43. It should not change its value merely by accessing its value. It's never done that in previous versions of perl, and shouldn't do it now. It's not the access. It's the print. Print may trigger a call into the C runtime library, which may result in errno changing, which, since errno is directly tied into $! and $^E, means that $! and $^E may change. The degenerate example I gave, with $^E not even holding its value across statements, is a rare but not impossible possibility -- if a signal hit in there and the signal handler did something that affected errno then $^E would change externally. If you're saying that the value of $! changing after $^E changes is not surprising, yes, I agree. But the value of $^E changing is very surprising, and wrong. Not wrong. Your assumptions about what's going on just turn out not to be correct. $^E and $! are tied to an external data cell (in this case the same cell) and while changes to $^E/$! will change that cell, changes to that cell from external code will change $^E/$!. Ultimately my bet is that Apple made a change in the C RTL that made errno get twiddled more than it used to be, which is perfectly reasonable. errno, and therefore $!/$^E, is only valid after a failed system call. After a successful one its value is undefined. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: $^E bug and perl 5.8.0
At 11:13 -0500 2003.11.19, Dan Sugalski wrote: On Wed, 19 Nov 2003, Rafael Garcia-Suarez wrote: Dan Sugalski wrote: Basically you're using a variable that can be affected by external things in a way that pretty much guarantees that external things will be happening. That it changes isn't much of a surprise. ($!/$^E may get modified by some signal handlers too, depending on what you do, so there's not even any guarantee that $^E = 42; $^E++; will end up with $^E set to 43. Using the Mac OS X equivalent of truss/strace might help to find out why errno changes there. My bet would be that the print triggers an errno update, which strikes me as perfectly reasonable. Yes, I just realized you might think that, and I should have been more descriptive: it happens regardless of print. $ ktrace perl -le '$! = -1728; $x = $^E+0; $y = $^E+0; print $x; print $y' -1728 22 It has nothing to do with addition, either: :-) $ ktrace perl -le '$! = -1728; $x = $^E; $y = $^E; print $x; print $y' Unknown error: -1728 Invalid argument And since it doesn't change with $!, it is not merely because the error is unknown: $ ktrace perl -le '$! = -1728; $x = $!; $y = $!; print $x; print $y' Unknown error: -1728 Unknown error: -1728 Also, the ktrace output of that is identical to the output of the original (modulo addresses and PIDs): $ ktrace perl -le '$! = -1728; print $^E+0 for 0,1' -1728 22 No syscalls between the two assignments. No reason for errno to update. And even if it did, why would it only update when $^E is printed, and not $!? ktrace/kdump output below if anyone cares. But there's got to be something different about $^E from $! that is causing this bug. 1343 ktrace RET ktrace 0 1343 ktrace CALL execve(0xb3b0,0xb9e8,0xb9f8) 1343 ktrace NAMI /Users/pudge/bin/perl 1343 ktrace RET execve -1 errno 2 No such file or directory 1343 ktrace CALL execve(0xb3b0,0xb9e8,0xb9f8) 1343 ktrace NAMI /usr/local/slash/bin/perl 1343 ktrace RET execve -1 errno 2 No such file or directory 1343 ktrace CALL execve(0xb3b0,0xb9e8,0xb9f8) 1343 ktrace NAMI /usr/local/apache/bin/perl 1343 ktrace RET execve -1 errno 2 No such file or directory 1343 ktrace CALL execve(0xb3b0,0xb9e8,0xb9f8) 1343 ktrace NAMI /usr/local/bin/perl 1343 ktrace NAMI /usr/lib/dyld 1343 perl RET execve 0 1343 perl CALL getuid 1343 perl RET getuid 502/0x1f6 1343 perl CALL getuid 1343 perl RET getuid 502/0x1f6 1343 perl CALL getuid 1343 perl RET getuid 502/0x1f6 1343 perl CALL getgid 1343 perl RET getgid 20/0x14 1343 perl CALL getgid 1343 perl RET getgid 20/0x14 1343 perl CALL open(0x13d8,0,0) 1343 perl NAMI /usr/local/lib/perl5/5.8.0/darwin/CORE/libperl.dylib 1343 perl RET open 3 1343 perl CALL fstat(0x3,0xb770) 1343 perl RET fstat 0 1343 perl CALL close(0x3) 1343 perl RET close 0 1343 perl CALL open(0x1428,0,0) 1343 perl NAMI /usr/lib/libSystem.B.dylib 1343 perl RET open 3 1343 perl CALL fstat(0x3,0xb770) 1343 perl RET fstat 0 1343 perl CALL load_shared_file(0x1428,0x22b000,0x1798fc,0xb580,0x4,0xb510,0xb584) 1343 perl NAMI /usr/lib/libSystem.B.dylib 1343 perl RET load_shared_file 0 1343 perl CALL close(0x3) 1343 perl RET close 0 1343 perl CALL open(0x96e8,0,0) 1343 perl NAMI /usr/lib/system/libmathCommon.A.dylib 1343 perl RET open 3 1343 perl CALL fstat(0x3,0xb700) 1343 perl RET fstat 0 1343 perl CALL load_shared_file(0x96e8,0x7000,0x6ac4,0xb510,0x3,0xb4a0,0xb514) 1343 perl NAMI /usr/lib/system/libmathCommon.A.dylib 1343 perl RET load_shared_file 0 1343 perl CALL close(0x3) 1343 perl RET close 0 1343 perl CALL __sysctl(0xb918,0x2,0xb920,0xb924,0,0) 1343 perl RET __sysctl 0 1343 perl CALL sigaction(0x8,0xb850,0xb8c0) 1343 perl RET sigaction 0 1343 perl CALL getuid 1343 perl RET getuid 502/0x1f6 1343 perl CALL getuid 1343 perl RET getuid 502/0x1f6 1343 perl CALL getgid 1343 perl RET getgid 20/0x14 1343 perl CALL getgid 1343 perl RET getgid 20/0x14 1343 perl CALL open(0x3011c0,0,0x1b6) 1343 perl NAMI /dev/null 1343 perl RET open 3 1343 perl CALL fcntl(0x3,0x2,0x1) 1343 perl RET fcntl 0 1343 perl CALL sigaction(0x14,0,0xb3e0) 1343 perl RET sigaction 0 1343 perl CALL getpid 1343 perl RET getpid 1343/0x55a 1343 perl CALL close(0x3) 1343 perl RET close 0 1343 perl CALL fstat(0x1,0xb100) 1343 perl RET fstat 0 1343 perl CALL ioctl(0x1,FIODTYPE,0xb150) 1343 perl RET
Re: $^E bug and perl 5.8.0
At 16:50 +0100 2003.11.19, Rafael Garcia-Suarez wrote:
Try this naive patch :
--- mg.c.orig Wed Nov 19 16:41:47 2003
+++ mg.c Wed Nov 19 16:44:14 2003
@@ -623,8 +623,12 @@ Perl_magic_get(pTHX_ SV *sv, MAGIC *mg)
SetLastError(dwErr);
}
#else
- sv_setnv(sv, (NV)errno);
- sv_setpv(sv, errno ? Strerror(errno) : );
+ {
+ int saveerrno = errno;
+ sv_setnv(sv, (NV)errno);
+ sv_setpv(sv, errno ? Strerror(errno) : );
+ errno = saveerrno;
+ }
#endif
#endif
#endif
I'm a tool ... I neglected to remove the first two lines. D'oh! I think
you are on to it there, that Strerror() is failing and setting errno, which
is Bad. This patch does indeed fix the problem. Sorry for the false
negative the first time through.
Now I wonder why this DOESN'T fail with ithreads?
Some background: I use $^E in several Mac:: modules, from back when they
were for Mac OS only. Now, I do a little fudging and use the Mac::Errors
module to provide the same support on Mac OS X. $^E and $! don't work
together on Mac OS like they do on Mac OS X, so I can't just change to $!.
I've been quite careful to not depend on $^E after system calls, or if I
need it, to save it and restore it later. In this case, it was changing
its value here:
$^E = exists $evt-{ERRNO} ? $evt-{ERRNO} : 0; # restore errno
my $return = 1;
# if error handler, only return if error handler returns true
# what should error handler be passed?
if ($^E $error_handler) {
# ... call $error_handler
}
return $return;
And even if $error_handler was false, $^E would end up incorrect after the
return. No syscalls.
However, the code above is broken anyway, as Dan might point out, since
$error_handler COULD contain syscalls, so I am modifying this particular
code to set $^E right before the return, and use a lexical var for the
other stuff. That fixes the immediate problem, and it is more robust in
case $error_handler does contain a syscall.
Anyway, thanks for the patch; I recommend its inclusion for 5.8.3/5.9, and
a test for it might be reasonable (I can come up with one, but not sure
where to put it, and not sure if I would cover all the bases properly ...).
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: $^E bug and perl 5.8.0
On Wed, 19 Nov 2003, Chris Nandor wrote: However, the code above is broken anyway, as Dan might point out, since $error_handler COULD contain syscalls, so I am modifying this particular code to set $^E right before the return, and use a lexical var for the other stuff. That fixes the immediate problem, and it is more robust in case $error_handler does contain a syscall. I was insufficiently pedantic -- it's not just system calls that can change errno (just checked). Any C library function can do so. Including, unfortunately, malloc. Luckily there's right-to-left ordering of evaluation (more or less) so $foo = $!; will be OK. Anything fancier, though, that could involve a function call (including plain stringification) may not be. Bring on the Heisenbugs! I think I'll take steps to make this less likely for Parrot, though I'm not sure there's truly any good way to get around it anywhere but in the actual application code. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: $^E bug and perl 5.8.0
Chris Nandor wrote: (For the porters: the bug is that this: % perl -le '$^E = -1728; print $^E+0 for 0,1' Should return this: -1728 -1728 But in some cases, returns this: -1728 22 Odd.) What does perl -le 'print $!=22' on your system ? Can you reproduce this bug with $! in place of $^E ?
Re: $^E bug and perl 5.8.0
Chris Nandor wrote:
At 16:39 +0100 2003.11.19, Rafael Garcia-Suarez wrote:
What does
perl -le 'print $!=22'
on your system ?
22.
Hmm, weird -- on my Linux 2.2 it prints correctly Invalid argument.
I wanted to know what was this errno corresponding to.
(but I can't reproduce your bug either)
Try this naive patch :
--- mg.c.orig Wed Nov 19 16:41:47 2003
+++ mg.cWed Nov 19 16:44:14 2003
@@ -623,8 +623,12 @@ Perl_magic_get(pTHX_ SV *sv, MAGIC *mg)
SetLastError(dwErr);
}
#else
-sv_setnv(sv, (NV)errno);
-sv_setpv(sv, errno ? Strerror(errno) : );
+{
+int saveerrno = errno;
+sv_setnv(sv, (NV)errno);
+sv_setpv(sv, errno ? Strerror(errno) : );
+errno = saveerrno;
+}
#endif
#endif
#endif
Re: $^E bug and perl 5.8.0
Dan Sugalski wrote: Given that on Unix systems $^E and $! are identical, and that $! is directly tied to errno, this certainly isn't surprising. Anything that afects errno (like, say, IO) may then affect $! and $^E identically.(And $!/$^E non-indentically on systems where they're separate) On Unix the implementation of $! and $^E should be the same -- that's fixed by the patch I sent (although a more proper version would refactor it (and add tests:)) Basically you're using a variable that can be affected by external things in a way that pretty much guarantees that external things will be happening. That it changes isn't much of a surprise. ($!/$^E may get modified by some signal handlers too, depending on what you do, so there's not even any guarantee that $^E = 42; $^E++; will end up with $^E set to 43. Using the Mac OS X equivalent of truss/strace might help to find out why errno changes there.
Re: $^E bug and perl 5.8.0
Try this naive patch : --- mg.c.orig Wed Nov 19 16:41:47 2003 +++ mg.c Wed Nov 19 16:44:14 2003 Now applied as #21743 to bleadperl. Considering the intricacies of the #ifdef forest in there, I left out refactoring with $! for now.
