develooper Front page | perl.perl5.porters | Postings from September 2010

[rt.cpan.org #56225] Innocent-looking Cwd change breaks EPIC + debugger on win32

From:
https://www.google.com/accounts/o8/id?id=AItOawn_DiEb3KC_WyL1eDoRstaKxFknWBpUgiw via RT
Date:
September 19, 2010 11:12
Subject:
[rt.cpan.org #56225] Innocent-looking Cwd change breaks EPIC + debugger on win32
Message ID:
rt-3.8.HEAD-24883-1284876015-1619.56225-6-0@rt.cpan.org
<URL: https://rt.cpan.org/Ticket/Display.html?id=56225 >

On Sat Sep 11 17:08:00 2010, jploski wrote:
> 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:
> > 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. 




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About