Bug #56225 for PathTools: Innocent-looking Cwd change breaks EPIC + debugger on win32

Fri Apr 02 08:45:12 2010 jpl [...] plosquare.com - Ticket created

A minor undocumented change to Cwd.pm introduced in release 3.31 of PathTools prevents the EPIC debugger frontend from working under Windows. Version 3.28_01 of PathTools works correctly. This is the fatal change: sub _win32_cwd { - if (defined &DynaLoader::boot_DynaLoader) { + if (eval 'defined &DynaLoader::boot_DynaLoader') { $ENV{'PWD'} = Win32::GetCwd(); } else { # miniperl The original EPIC bug report can be found here: https://sourceforge.net/tracker/? func=detail&aid=2907155&group_id=75859&atid=545274 Background information: while in debugging mode, EPIC invokes perl -d with an -I path that points to a directory with a patched version of the perl5db.pl file from the local Perl installation. The EPIC patch consists of the following code: # Do we have any breakpoints to put in this file? { use epic_breakpoints; my $osingle = $single; $single = 0; $single = epic_breakpoints::_postponed($filename, $line) || $osingle; } In epic_breakpoints.pm we have the statement "use Cwd 'abs_path';" Within this context the attempt to compile perl5db.pl with PathTools 3.31 before it is invoked fails with the following message: Use of uninitialized value in subroutine dereference at (null) line 1. perl5db.pl did not return a true value. BEGIN failed--compilation aborted. Can you undo the offending change or, if it was intentional, suggest a workaround that could be implemented in EPIC? Right now EPIC users must be advised to patch their Cwd.pm manually in order to restore the correct functionality.

Fri Sep 10 13:44:27 2010 https://www.google.com/accounts/o8/id?id=AItOawn_DiEb3KC_WyL1eDoRstaKxFknWBpUgiw - Correspondence added

Subject:	Bump
From:	Garen

Ping? The fix for this is so trivial and straightforward and fixes debugging on Windows.

Fri Sep 10 13:44:28 2010 The RT System itself - Status changed from 'new' to 'open'

Fri Sep 10 14:17:43 2010 kwilliams [...] cpan.org - Correspondence added

This change was made first in core perl and then later merged into Cwd.pm, so unfortunately I'm not really sure what motivated it. What happens if you change this: if (eval 'defined &DynaLoader::boot_DynaLoader') { to this: if (eval 'use DynaLoader; defined &DynaLoader::boot_DynaLoader') { ? -Ken

Fri Sep 10 15:27:27 2010 jpl [...] plosquare.com - Correspondence added

From:

jpl [...] plosquare.com

Same problem as before with this change. On Fri Sep 10 14:17:43 2010, KWILLIAMS wrote: Show quoted text

> This change was made first in core perl and then later merged into > Cwd.pm, so unfortunately I'm not really sure what motivated it. > > What happens if you change this: > > if (eval 'defined &DynaLoader::boot_DynaLoader') { > > to this: > > if (eval 'use DynaLoader; defined &DynaLoader::boot_DynaLoader') { > > ? > > -Ken

Fri Sep 10 16:17:48 2010 https://www.google.com/accounts/o8/id?id=AItOawn_DiEb3KC_WyL1eDoRstaKxFknWBpUgiw - Correspondence added

Subject:	Working patch
From:	Garen

Ditto - the only thing that has worked for me is the suggested patch from the EPIC forums. Attaching to this message; works for me using Komodo with Strawberry Perl 5.12.1 and ActiveState Perl 5.12.2.

Subject:

cwd_debug_fix.patch

--- vanilla_Cwd.pm 2010-04-26 02:08:28.000000000 -0700 +++ Cwd.pm 2010-09-09 15:35:14.000000000 -0700 @@ -748,7 +748,7 @@ } sub _win32_cwd { - if (eval 'defined &DynaLoader::boot_DynaLoader') { + if (eval { defined &DynaLoader::boot_DynaLoader; }) { $ENV{'PWD'} = Win32::GetCwd(); } else { # miniperl

Sat Sep 11 03:19:05 2010 smueller [...] cpan.org - Cc p5p added

Sat Sep 11 03:20:09 2010 smueller [...] cpan.org - Correspondence added

Subject:

Innocent-looking Cwd change breaks EPIC + debugger on win32

I'm quoting the original bug report for those reading along on p5p: Show quoted text

> A minor undocumented change to Cwd.pm introduced in release 3.31 of > PathTools prevents the EPIC debugger frontend from working under > Windows. Version 3.28_01 of PathTools works correctly. This is the > fatal change: > > sub _win32_cwd { > - if (defined &DynaLoader::boot_DynaLoader) { > + if (eval 'defined &DynaLoader::boot_DynaLoader') { > $ENV{'PWD'} = Win32::GetCwd(); > } > else { # miniperl > > The original EPIC bug report can be found here: > > https://sourceforge.net/tracker/? > func=detail&aid=2907155&group_id=75859&atid=545274 > > Background information: while in debugging mode, EPIC invokes perl -d > with an -I path that points to a directory with a patched version of > the perl5db.pl file from the local Perl installation. The EPIC patch > consists of the following code: > > # Do we have any breakpoints to put in this file? > { use epic_breakpoints; my $osingle = $single; $single = 0; $single > = epic_breakpoints::_postponed($filename, $line) || $osingle; } > > In epic_breakpoints.pm we have the statement "use Cwd 'abs_path';" > > Within this context the attempt to compile perl5db.pl with PathTools > 3.31 before it is invoked fails with the following message: > > Use of uninitialized value in subroutine dereference at (null) line 1. > perl5db.pl did not return a true value. > BEGIN failed--compilation aborted. > > Can you undo the offending change or, if it was intentional, suggest a > workaround that could be implemented in EPIC? Right now EPIC users > must be advised to patch their Cwd.pm manually in order to restore > the correct functionality.

On Fri Sep 10 16:17:48 2010, https://www.google.com/accounts/o8/id?id=AItOawn_DiEb3KC_WyL1eDoRstaKxFknWBpUgiw wrote: Show quoted text

> Ditto - the only thing that has worked for me is the suggested patch > from the EPIC forums. Attaching to this message; works for me using > Komodo with Strawberry Perl 5.12.1 and ActiveState Perl 5.12.2. >

A friendly soul on IRC (Nicholas) dug out the original discussion of the change that's causing trouble for you: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2009-09/msg00326.html Please read that carefully (starting from the first follow-up). We cannot revert the change without exposing another bug. Either one could be investigated, but I assume finding out why this is causing trouble for you in the debugger would be the natural place to start. I don't have a good idea on what the culprit could be. --Steffen

Sat Sep 11 03:20:42 2010 smueller [...] cpan.org - Subject changed from (no value) to 'Innocent-looking Cwd change breaks EPIC + debugger on win32'

Sat Sep 11 04:04:34 2010 https://www.google.com/accounts/o8/id?id=AItOawn_DiEb3KC_WyL1eDoRstaKxFknWBpUgiw - Correspondence added

From:

Garen

The proposed patch from the EPIC forums doesn't revert the fix - it does the eval inside of a curly brace block instead of inside a quoted string. Why that happens to work I have no idea, but wouldn't be surprised if it also fixes the original "bug" on the ancient win2k system from the original post in 2009 that inspired the current "fix". Anyone still have a win2k system to confirm? :) On Sat Sep 11 03:20:09 2010, SMUELLER wrote: Show quoted text

> I'm quoting the original bug report for those reading along on p5p: >

> > A minor undocumented change to Cwd.pm introduced in release 3.31 of > > PathTools prevents the EPIC debugger frontend from working under > > Windows. Version 3.28_01 of PathTools works correctly. This is the > > fatal change: > > > > sub _win32_cwd { > > - if (defined &DynaLoader::boot_DynaLoader) { > > + if (eval 'defined &DynaLoader::boot_DynaLoader') { > > $ENV{'PWD'} = Win32::GetCwd(); > > } > > else { # miniperl > > > > The original EPIC bug report can be found here: > > > > https://sourceforge.net/tracker/? > > func=detail&aid=2907155&group_id=75859&atid=545274 > > > > Background information: while in debugging mode, EPIC invokes perl

> -d

> > with an -I path that points to a directory with a patched version of > > the perl5db.pl file from the local Perl installation. The EPIC patch > > consists of the following code: > > > > # Do we have any breakpoints to put in this file? > > { use epic_breakpoints; my $osingle = $single; $single = 0; $single > > = epic_breakpoints::_postponed($filename, $line) || $osingle; } > > > > In epic_breakpoints.pm we have the statement "use Cwd 'abs_path';" > > > > Within this context the attempt to compile perl5db.pl with PathTools > > 3.31 before it is invoked fails with the following message: > > > > Use of uninitialized value in subroutine dereference at (null) line

> 1.

> > perl5db.pl did not return a true value. > > BEGIN failed--compilation aborted. > > > > Can you undo the offending change or, if it was intentional, suggest

> a

> > workaround that could be implemented in EPIC? Right now EPIC users > > must be advised to patch their Cwd.pm manually in order to restore > > the correct functionality.

> > On Fri Sep 10 16:17:48 2010, >

https://www.google.com/accounts/o8/id?id=AItOawn_DiEb3KC_WyL1eDoRstaKxFknWBpUgiw Show quoted text

> wrote:

> > Ditto - the only thing that has worked for me is the suggested patch > > from the EPIC forums. Attaching to this message; works for me using > > Komodo with Strawberry Perl 5.12.1 and ActiveState Perl 5.12.2. > >

> > A friendly soul on IRC (Nicholas) dug out the original discussion of > the > change that's causing trouble for you: > > http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2009- > 09/msg00326.html > > Please read that carefully (starting from the first follow-up). We > cannot revert the change without exposing another bug. Either one > could > be investigated, but I assume finding out why this is causing trouble > for you in the debugger would be the natural place to start. I don't > have a good idea on what the culprit could be. > > --Steffen

Sat Sep 11 14:14:04 2010 nick [...] ccl4.org - Correspondence added

CC:	jpl [...] plosquare.com, perl5-porters [...] perl.org
Subject:	Re: [rt.cpan.org #56225] Innocent-looking Cwd change breaks EPIC + debugger on win32
Date:	Sat, 11 Sep 2010 19:13:55 +0100
To:	"https://www.google.com/accounts/o8/id?id=AItOawn_DiEb3KC_WyL1eDoRstaKxFknWBpUgiw via RT" <bug-PathTools [...] rt.cpan.org>
From:	Nicholas Clark <nick [...] ccl4.org>

On Sat, Sep 11, 2010 at 04:04:35AM -0400, https://www.google.com/accounts/o8/id?id=AItOawn_DiEb3KC_WyL1eDoRstaKxFknWBpUgiw via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=56225 > > > The proposed patch from the EPIC forums doesn't revert the fix - it does > the eval inside of a curly brace block instead of inside a quoted string.

Try it. I predict that it's not going to work. (In that it will re-create the bug that this fixed, unless something else has changed). The point of the *string* eval was to avoid early (well normal) binding the CV to the optree, given that later in execution the CV gets deleted. (by MakeMaker::Test::NoXS to simulate miniperl) Thread related to all of this http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2009-09/msg00326.html (which you reference below) Show quoted text

> Why that happens to work I have no idea, but wouldn't be surprised if it > also fixes the original "bug" on the ancient win2k system from the > original post in 2009 that inspired the current "fix". > > Anyone still have a win2k system to confirm? :)

I don't think that this is win2k specific. My hunch is that it will have the same "problem" on anything win32. However, I don't have a win32 system to test that out on. Show quoted text

> On Sat Sep 11 03:20:09 2010, SMUELLER wrote:

> > I'm quoting the original bug report for those reading along on p5p:

Show quoted text

> > A friendly soul on IRC (Nicholas) dug out the original discussion of > > the > > change that's causing trouble for you: > > > > http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2009- > > 09/msg00326.html > > > > Please read that carefully (starting from the first follow-up). We > > cannot revert the change without exposing another bug. Either one > > could > > be investigated, but I assume finding out why this is causing trouble > > for you in the debugger would be the natural place to start. I don't > > have a good idea on what the culprit could be.

There is some sort of real bug here, if doing a string eval causes strange SV behaviour. Nicholas Clark

Sat Sep 11 16:16:07 2010 rgs [...] consttype.org - Correspondence added

CC:	jpl [...] plosquare.com, perl5-porters [...] perl.org
Subject:	Re: [rt.cpan.org #56225] Innocent-looking Cwd change breaks EPIC + debugger on win32
Date:	Sat, 11 Sep 2010 22:15:58 +0200
To:	bug-PathTools [...] rt.cpan.org
From:	Rafael Garcia-Suarez <rgs [...] consttype.org>

On 11 September 2010 09:20, Steffen Mueller via RT <bug-PathTools@rt.cpan.org> wrote: Show quoted text

>> Background information: while in debugging mode, EPIC invokes perl -d >> with an -I path that points to a directory with a patched version of >> the perl5db.pl file from the local Perl installation. The EPIC patch >> consists of the following code:

[...] at this point I'd like to ask: why not use the "perl -d:Foo" syntax instead ?

Sat Sep 11 17:08:00 2010 jpl [...] plosquare.com - Correspondence added

From:

jpl [...] plosquare.com

To everyone, thanks for having a look into this. There is no good reason why -d:Foo is not used by EPIC, but I don't think it would change anything in the observed behavior - do you? Here are a few more observations: (1) This behavior is not win2k specific. I'm also seeing it in Windows 7. (2) Doing any string eval (e.g. eval '1') anywhere in that particular stack context causes the same trouble. So strictly speaking, it's not a Cwd.pm bug. It's just that Cwd happens to be used by EPIC in this particular context and it contains an (otherwise harmless) string eval. Here is a sample call stack trace in which a string eval becomes evil: at C:/Perl/lib/Cwd.pm line 660 Cwd::fast_abs_path('C:/Users/admin/workspace.debug/HelloPerl/') called at C:/Perl/lib/Cwd.pm line 652 Cwd::fast_abs_path('C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl') called at C:/Users/admin/workspace.debug/.metadata/.plugins/org.epic.debug/epic_breakpoints.pm line 76 eval {...} called at C:/Users/admin/workspace.debug/.metadata/.plugins/org.epic.debug/epic_breakpoints.pm line 76 epic_breakpoints::_abs_path('C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl') called at C:/Users/admin/workspace.debug/.metadata/.plugins/org.epic.debug/epic_breakpoints.pm line 133 epic_breakpoints::_postponed('C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl', undef) called at C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl line 5527 DB::postponed('*main::_<C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl') called at C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl line 0 require perl5db.pl called at C:/Users/admin/workspace.debug/HelloPerl/hello.pl line 0 main::BEGIN() called at C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl line 0 eval {...} called at C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl line 0 perl5db.pl did not return a true value. BEGIN failed--compilation aborted. Actually, it doesn't fail instantly at the point of eval, nor even within that stack trace. Several such stack traces appear in my debugging output before the debugger eventuelly collapses (this one quoted here is the last one, hence final the error message with "compilation aborted"). I suspect it has something to do with perl5db.pl itself redefining sub eval, but I'm not enough of a Perl hacker to explain what is exactly going on. I'm going to check whether the same trouble with eval occurs under Linux. Of course, the _win32_cwd path is not taken in Cwd.pm under Linux, which is why the problem popped up as Windows-specific in EPIC bug tracker, but that's beside the point. I lean toward either it's a genuine implementation bug in Perl or a case of illegal use of certain constructs under special circumstances (an EPIC bug due to my ignorance or alternatively an underspecification bug in Perl). On Sat Sep 11 16:16:07 2010, rgs@consttype.org wrote: Show quoted text

> On 11 September 2010 09:20, Steffen Mueller via RT > <bug-PathTools@rt.cpan.org> wrote:

> >> Background information: while in debugging mode, EPIC invokes perl

> -d

> >> with an -I path that points to a directory with a patched version

> of

> >> the perl5db.pl file from the local Perl installation. The EPIC

> patch

> >> consists of the following code:

> [...] > > at this point I'd like to ask: why not use the "perl -d:Foo" syntax > instead ?

Sun Sep 19 02:00:14 2010 https://www.google.com/accounts/o8/id?id=AItOawn_DiEb3KC_WyL1eDoRstaKxFknWBpUgiw - Correspondence added

From:

Garen

On Sat Sep 11 17:08:00 2010, jploski wrote: Show quoted text

> To everyone, thanks for having a look into this. > > There is no good reason why -d:Foo is not used by EPIC, but I don't > think it would change anything in the observed behavior - do you? > > Here are a few more observations: > > (1) This behavior is not win2k specific. I'm also seeing it in Windows > 7. > > (2) Doing any string eval (e.g. eval '1') anywhere in that particular > stack context causes the same trouble. So strictly speaking, it's not > a > Cwd.pm bug. It's just that Cwd happens to be used by EPIC in this > particular context and it contains an (otherwise harmless) string > eval. > Here is a sample call stack trace in which a string eval becomes evil: > > at C:/Perl/lib/Cwd.pm line 660 > Cwd::fast_abs_path('C:/Users/admin/workspace.debug/HelloPerl/') > called > at C:/Perl/lib/Cwd.pm line 652 > Cwd::fast_abs_path('C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl') > called at >

C:/Users/admin/workspace.debug/.metadata/.plugins/org.epic.debug/epic_breakpoints.pm Show quoted text

> line 76 > eval {...} called at >

C:/Users/admin/workspace.debug/.metadata/.plugins/org.epic.debug/epic_breakpoints.pm Show quoted text

> line 76 >

epic_breakpoints::_abs_path('C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl') Show quoted text

> called at >

C:/Users/admin/workspace.debug/.metadata/.plugins/org.epic.debug/epic_breakpoints.pm Show quoted text

> line 133 >

epic_breakpoints::_postponed('C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl', Show quoted text

> undef) called at C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl > line 5527 >

DB::postponed('*main::_<C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl') Show quoted text

> called at C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl line 0 > require perl5db.pl called at > C:/Users/admin/workspace.debug/HelloPerl/hello.pl line 0 > main::BEGIN() called at > C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl line 0 > eval {...} called at > C:/Users/admin/workspace.debug/HelloPerl/perl5db.pl line 0 > perl5db.pl did not return a true value. > BEGIN failed--compilation aborted. > > Actually, it doesn't fail instantly at the point of eval, nor even > within that stack trace. Several such stack traces appear in my > debugging output before the debugger eventuelly collapses (this one > quoted here is the last one, hence final the error message with > "compilation aborted"). > > I suspect it has something to do with perl5db.pl itself redefining sub > eval, but I'm not enough of a Perl hacker to explain what is exactly > going on. I'm going to check whether the same trouble with eval occurs > under Linux. Of course, the _win32_cwd path is not taken in Cwd.pm > under > Linux, which is why the problem popped up as Windows-specific in EPIC > bug tracker, but that's beside the point. > > I lean toward either it's a genuine implementation bug in Perl or a > case > of illegal use of certain constructs under special circumstances (an > EPIC bug due to my ignorance or alternatively an underspecification > bug > in Perl). > > On Sat Sep 11 16:16:07 2010, rgs@consttype.org wrote:

> > On 11 September 2010 09:20, Steffen Mueller via RT > > <bug-PathTools@rt.cpan.org> wrote:

> > >> Background information: while in debugging mode, EPIC invokes

> perl

> > -d

> > >> with an -I path that points to a directory with a patched version

> > of

> > >> the perl5db.pl file from the local Perl installation. The EPIC

> > patch

> > >> consists of the following code:

> > [...] > > > > at this point I'd like to ask: why not use the "perl -d:Foo" syntax > > instead ?

> >

I was hoping to come up with a minimized test case for this issue, but after hours of trying, can't come up with anything. I also tried to reproduce the original issue from 11 Sep 2009 with Strawberry Perl 5.12.1 on Windows XP 32-bit and Windows 7 x64 by running 'test ExtUtils::MakeMaker' but couldn't reproduce the failure. I tried all three combinations of the line of interest from Cwd.pm in each environment: 1) Cwd.pm code as it was prior to the patch on 11 Sep 2009: if (defined &DynaLoader::boot_DynaLoader) { ... 2) Cwd.pm code as it is now in 5.12 if (eval 'use DynaLoader; defined &DynaLoader::boot_DynaLoader') { ... 3) Cwd.pm code with the curly brace eval patch, attached to this bug: if (eval { defined &DynaLoader::boot_DynaLoader; }) { ... In all three cases, all tests pass.

Fri Jun 17 12:08:06 2011 vvm [...] tut.by - Correspondence added

From:

vvm [...] tut.by

On Fri Apr 02 08:45:12 2010, jploski wrote: Show quoted text

> A minor undocumented change to Cwd.pm introduced in release 3.31 of > PathTools prevents the EPIC debugger frontend from working under > Windows. Version 3.28_01 of PathTools works correctly. This is the > fatal change: > > sub _win32_cwd { > - if (defined &DynaLoader::boot_DynaLoader) { > + if (eval 'defined &DynaLoader::boot_DynaLoader') { > $ENV{'PWD'} = Win32::GetCwd(); > } > else { # miniperl

on SB Perl x64: == sub _win32_cwd { # Orig -- bad ## if (eval 'defined &DynaLoader::boot_DynaLoader') { # Non full Ok ## if (eval { defined &DynaLoader::boot_DynaLoader } ) { #VVM Ok ## if ( &DynaLoader::boot_DynaLoader) { #VVM Ok N2 if ( defined &DynaLoader::boot_DynaLoader) { ==

Sat Jun 18 06:08:16 2011 rurban [...] x-ray.at - Correspondence added

CC:	jpl [...] plosquare.com, perl5-porters [...] perl.org
Subject:	Re: [rt.cpan.org #56225] Innocent-looking Cwd change breaks EPIC + debugger on win32
Date:	Sat, 18 Jun 2011 05:08:07 -0500
To:	bug-PathTools [...] rt.cpan.org
From:	Reini Urban <rurban [...] x-ray.at>

2011/6/17 Victor Miasnikov via RT <bug-PathTools@rt.cpan.org>: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=56225 > > > On Fri Apr 02 08:45:12 2010, jploski wrote: >

>> A minor undocumented change to Cwd.pm introduced in release 3.31 of >> PathTools prevents the EPIC debugger frontend from working under >> Windows. Version 3.28_01 of PathTools works correctly. This is the >> fatal change: >> >> sub _win32_cwd { >> - if (defined &DynaLoader::boot_DynaLoader) { >> + if (eval 'defined &DynaLoader::boot_DynaLoader') { >> $ENV{'PWD'} = Win32::GetCwd(); >> } >> else { # miniperl

> > on SB Perl x64: > > == > sub _win32_cwd { > # Orig -- bad ## if (eval 'defined &DynaLoader::boot_DynaLoader') { > # Non full Ok ## if (eval { defined &DynaLoader::boot_DynaLoader } ) { > #VVM Ok ## if ( &DynaLoader::boot_DynaLoader) { > #VVM Ok N2 > if ( defined &DynaLoader::boot_DynaLoader) { > ==

The purpose of the string eval was to avoid autovivication of the CV. If the context stack is broken on win32 somehow, a different, less intrusive fix would be: if ( *DynaLoader::boot_DynaLoader{CODE} ) { -- Reini Urban

Mon Jun 20 10:46:20 2011 vvm [...] tut.by - Correspondence added

From:

vvm [...] tut.by

Show quoted text

>> 2011/6/17 Victor Miasnikov via RT <bug-PathTools@rt.cpan.org>:

>On Sat Jun 18 06:08:16 2011, rurban@x-ray.at wrote: > a different, less intrusive fix would be: > > if ( *DynaLoader::boot_DynaLoader{CODE} ) { >

Yes -- work Ok == sub _win32_cwd { #Reini Urban Var Ok## if ( *DynaLoader::boot_DynaLoader{CODE} ) { ==

Thu Jul 07 09:55:49 2011 nick [...] ccl4.org - Correspondence added

Subject:	Re: [rt.cpan.org #56225] Innocent-looking Cwd change breaks EPIC + debugger on win32
Date:	Thu, 7 Jul 2011 14:55:36 +0100
To:	"https://www.google.com/accounts/o8/id?id=AItOawn_DiEb3KC_WyL1eDoRstaKxFknWBpUgiw via RT" <bug-PathTools [...] rt.cpan.org>, jpl [...] plosquare.com, perl5-porters [...] perl.org, Reini Urban <rurban [...] x-ray.at>
From:	Nicholas Clark <nick [...] ccl4.org>

On Sat, Sep 11, 2010 at 07:13:55PM +0100, Nicholas Clark wrote: Show quoted text

> Try it. I predict that it's not going to work. > > (In that it will re-create the bug that this fixed, unless something else has > changed). > The point of the *string* eval was to avoid early (well normal) binding the CV > to the optree, given that later in execution the CV gets deleted. > (by MakeMaker::Test::NoXS to simulate miniperl) > > Thread related to all of this > http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2009-09/msg00326.html > (which you reference below)

On Sat, Jun 18, 2011 at 05:08:07AM -0500, Reini Urban wrote: Show quoted text

> The purpose of the string eval was to avoid autovivication of the CV. > > If the context stack is broken on win32 somehow, > a different, less intrusive fix would be: > > if ( *DynaLoader::boot_DynaLoader{CODE} ) { >

However that construction doesn't actually address the issue I described above, because: ./perl -le 'delete $DynaLoader::{boot_DynaLoader}; print defined *DynaLoader::boot_DynaLoader{CODE}' 1 whereas we want a construction that returns 0 after C<delete $DynaLoader::{boot_DynaLoader}> has been run. Inspired by Reini's approach, I committed this: commit 5ec06e76dc20e3154110c2955f25db63f00c527d Author: Nicholas Clark <nick@ccl4.org> Date: Sat Jun 18 14:42:07 2011 +0200 In Cwd::_win32_cwd() avoid a string eval when checking if we're miniperl. To allow ExtUtils::MakeMaker to run tests as if it's "miniperl" we need to avoid taking any sort of reference to the typeglob or the code in the optree, as its test modules are loaded later than Cwd. Previously this was done with a string eval, but that was causing problems (for unclear reasons - rt.cpan.org #56225). Using a symbol table lookup and *foo{THING} syntax avoids the string eval. Evolved from a suggestion by Reini Urban. diff --git a/dist/Cwd/Cwd.pm b/dist/Cwd/Cwd.pm index 4683e10..ecd14ae 100644 --- a/dist/Cwd/Cwd.pm +++ b/dist/Cwd/Cwd.pm @@ -171,7 +171,7 @@ use strict; use Exporter; use vars qw(@ISA @EXPORT @EXPORT_OK $VERSION); -$VERSION = '3.36'; +$VERSION = '3.37'; my $xs_version = $VERSION; $VERSION = eval $VERSION; @@ -755,7 +755,14 @@ sub _win32_cwd_simple { } sub _win32_cwd { - if (eval 'defined &DynaLoader::boot_DynaLoader') { + # Need to avoid taking any sort of reference to the typeglob or the code in + # the optree, so that this tests the runtime state of things, as the + # ExtUtils::MakeMaker tests for "miniperl" need to be able to fake things at + # runtime by deleting the subroutine. *foo{THING} syntax on a symbol table + # lookup avoids needing a string eval, which has been reported to cause + # problems (for reasons that we haven't been able to get to the bottom of - + # rt.cpan.org #56225) + if (*{$DynaLoader::{boot_DynaLoader}}{CODE}) { $ENV{'PWD'} = Win32::GetCwd(); } else { # miniperl On Mon, Jun 20, 2011 at 10:46:22AM -0400, Victor Miasnikov via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=56225 > >

> >> 2011/6/17 Victor Miasnikov via RT <bug-PathTools@rt.cpan.org>:

> >On Sat Jun 18 06:08:16 2011, rurban@x-ray.at wrote: > > a different, less intrusive fix would be: > > > > if ( *DynaLoader::boot_DynaLoader{CODE} ) { > >

> > Yes -- work Ok

As the string eval is the problem, I'm assuming that the change I made will solve the symptoms too. Nicholas Clark

Sun Nov 24 11:04:14 2013 jkeenan [...] cpan.org - Correspondence added

On Thu Jul 07 09:55:49 2011, nick@ccl4.org wrote: Show quoted text

> On Sat, Sep 11, 2010 at 07:13:55PM +0100, Nicholas Clark wrote:

> > Try it. I predict that it's not going to work. > > > > (In that it will re-create the bug that this fixed, unless something > > else has > > changed). > > The point of the *string* eval was to avoid early (well normal) > > binding the CV > > to the optree, given that later in execution the CV gets deleted. > > (by MakeMaker::Test::NoXS to simulate miniperl) > > > > Thread related to all of this > > http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2009- > > 09/msg00326.html > > (which you reference below)

> > On Sat, Jun 18, 2011 at 05:08:07AM -0500, Reini Urban wrote: >

> > The purpose of the string eval was to avoid autovivication of the CV. > > > > If the context stack is broken on win32 somehow, > > a different, less intrusive fix would be: > > > > if ( *DynaLoader::boot_DynaLoader{CODE} ) { > >

> > However that construction doesn't actually address the issue I > described > above, because: > > ./perl -le 'delete $DynaLoader::{boot_DynaLoader}; print defined > *DynaLoader::boot_DynaLoader{CODE}' > 1 > > whereas we want a construction that returns 0 after > C<delete $DynaLoader::{boot_DynaLoader}> has been run. Inspired by > Reini's > approach, I committed this: > > commit 5ec06e76dc20e3154110c2955f25db63f00c527d > Author: Nicholas Clark <nick@ccl4.org> > Date: Sat Jun 18 14:42:07 2011 +0200 > > In Cwd::_win32_cwd() avoid a string eval when checking if we're > miniperl. > > To allow ExtUtils::MakeMaker to run tests as if it's "miniperl" we > need to avoid > taking any sort of reference to the typeglob or the code in the > optree, as its > test modules are loaded later than Cwd. Previously this was done with > a string > eval, but that was causing problems (for unclear reasons - rt.cpan.org > #56225). > Using a symbol table lookup and *foo{THING} syntax avoids the string > eval. > > Evolved from a suggestion by Reini Urban. > > diff --git a/dist/Cwd/Cwd.pm b/dist/Cwd/Cwd.pm > index 4683e10..ecd14ae 100644 > --- a/dist/Cwd/Cwd.pm > +++ b/dist/Cwd/Cwd.pm > @@ -171,7 +171,7 @@ use strict; > use Exporter; > use vars qw(@ISA @EXPORT @EXPORT_OK $VERSION); > > -$VERSION = '3.36'; > +$VERSION = '3.37'; > my $xs_version = $VERSION; > $VERSION = eval $VERSION; > > @@ -755,7 +755,14 @@ sub _win32_cwd_simple { > } > > sub _win32_cwd { > - if (eval 'defined &DynaLoader::boot_DynaLoader') { > + # Need to avoid taking any sort of reference to the typeglob or > the code in > + # the optree, so that this tests the runtime state of things, as > the > + # ExtUtils::MakeMaker tests for "miniperl" need to be able to > fake things at > + # runtime by deleting the subroutine. *foo{THING} syntax on a > symbol table > + # lookup avoids needing a string eval, which has been reported to > cause > + # problems (for reasons that we haven't been able to get to the > bottom of - > + # rt.cpan.org #56225) > + if (*{$DynaLoader::{boot_DynaLoader}}{CODE}) { > $ENV{'PWD'} = Win32::GetCwd(); > } > else { # miniperl > > > On Mon, Jun 20, 2011 at 10:46:22AM -0400, Victor Miasnikov via RT > wrote:

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=56225 > > >

> > >> 2011/6/17 Victor Miasnikov via RT <bug-PathTools@rt.cpan.org>:

> > > On Sat Jun 18 06:08:16 2011, rurban@x-ray.at wrote: > > > a different, less intrusive fix would be: > > > > > > if ( *DynaLoader::boot_DynaLoader{CODE} ) { > > >

> > > > Yes -- work Ok

> > As the string eval is the problem, I'm assuming that the change I made > will > solve the symptoms too. > > Nicholas Clark

There has been no discussion in this ticket for over two years. Can we therefore conclude that Nicholas's patch has resolved the problem and that this ticket is closable? Thank you very much. Jim Keenan

Tue Nov 26 18:34:10 2013 jkeenan [...] cpan.org - Requestor JKEENAN added