Re: Reality checking a win32 perl bug

Wild guess: in both your examples you die in any case. This means that the program terminates with an exit value that is not null, i.e. technically, it fails. That is, it may not be an error, but exactly what is supposed to happen. Have you tried s/die/print/?

What are you really trying to achieve? What did you expect to happen?

perl -e "sub { @_ = sub {@_}->(@_); fork ? die 5 : die 6 }->(2)"
[download]

Hmmm... here you dereference a subref passing in 2 as an arg. Then you pass the whole argument list, that is (2), to another anonymous sub that will just return its arguments, and assign that back to the argument list, which is not changed after all. Having done all this you don't do anything with the input value, but simply fork and die both if you're the "forked" process or the parent one - or if the fork failed.

perl -e "sub { @_ = 3; fork ? die 5 : die 6 }->()"
[download]

Less byzantine, but still @_ = 3; does nothing, really.

Comment on Re: Reality checking a win32 perl bug Select or Download Code

Replies are listed 'Best First'.
Re^2: Reality checking a win32 perl bug by xdg (Monsignor) on May 16, 2006 at 11:26 UTC
The point is not that the program fails, but that it fails in a way that pops up the Windows Application Error dialog box -- i.e. perl.exe fails due to some sort of memory access error, which is different than the script failing. That's the bug. (Same with Tainted fork crash on Win32.) It seems to be triggered by assigning to `@_` in a fork. It's not the `die` or the anonymous sub. Even localizing it doesn't help. These variations crash perl.exe, too: `> perl -e "sub foo { @_ = (1); fork ? exit : exit } foo" > perl -e "sub foo { local @_ = (1); fork ? exit : exit } foo"` [download] -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Reality checking a win32 perl bug
by xdg (Monsignor) on May 16, 2006 at 11:26 UTC

The point is not that the program fails, but that it fails in a way that pops up the Windows Application Error dialog box -- i.e. perl.exe fails due to some sort of memory access error, which is different than the script failing. That's the bug. (Same with Tainted fork crash on Win32.)

It seems to be triggered by assigning to @_ in a fork. It's not the die or the anonymous sub. Even localizing it doesn't help. These variations crash perl.exe, too:

> perl -e "sub foo { @_ = (1); fork ? exit : exit } foo"

> perl -e "sub foo { local @_ = (1); fork ? exit : exit } foo"
[download]

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
[d/l]
[select]