Skip Menu |
 

This queue is for tickets about the PathTools CPAN distribution.

Report information
The Basics
Id: 56225
Status: open
Priority: 0/
Queue: PathTools

People
Owner: Nobody in particular
Requestors: jkeenan [...] cpan.org
jpl [...] plosquare.com
Cc: perl5-porters [...] perl.org
AdminCc:

Bug Information
Severity: Important
Broken in: 3.31
Fixed in: (no value)



MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 1562
Download (untitled) / with headers
text/plain 1.5k
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.
MIME-Version: 1.0
Subject: *Bump*
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Message-ID: <rt-3.8.HEAD-11057-1284140667-501.56225-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: binary
From: Garen
X-RT-Original-Encoding: utf-8
Content-Length: 89
Ping? The fix for this is so trivial and straightforward and fixes debugging on Windows.
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-11057-1284140667-501.56225-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-11057-1284140667-501.56225-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-11057-1284142663-271.56225-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 310
Download (untitled) / with headers
text/plain 310b
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
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-11057-1284142663-271.56225-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-11057-1284140667-501.56225-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-11057-1284142663-271.56225-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-11057-1284146847-1434.56225-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
From: jpl [...] plosquare.com
X-RT-Original-Encoding: utf-8
Content-Length: 428
Download (untitled) / with headers
text/plain 428b
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
MIME-Version: 1.0
Subject: Working patch
In-Reply-To: <rt-3.8.HEAD-11057-1284142663-271.56225-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
References: <rt-3.8.HEAD-11057-1284140667-501.56225-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-11057-1284142663-271.56225-0-0 [...] rt.cpan.org>
Content-Type: multipart/mixed; boundary="----------=_1284149868-11059-287"
Message-ID: <rt-3.8.HEAD-11059-1284149868-132.56225-0-0 [...] rt.cpan.org>
From: Garen
X-RT-Original-Encoding: utf-8
Content-Length: 0
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 203
Download (untitled) / with headers
text/plain 203b
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.
MIME-Version: 1.0
Subject: cwd_debug_fix.patch
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Type: application/octet-stream; name="cwd_debug_fix.patch"
Content-Disposition: inline; filename="cwd_debug_fix.patch"
Content-Transfer-Encoding: base64
Content-Length: 334
Download cwd_debug_fix.patch
text/x-diff 334b
--- 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
MIME-Version: 1.0
Subject: Innocent-looking Cwd change breaks EPIC + debugger on win32
In-Reply-To: <rt-3.8.HEAD-11059-1284149868-132.56225-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-11057-1284140667-501.56225-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-11057-1284142663-271.56225-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-11059-1284149868-132.56225-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-11061-1284189609-948.56225-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 2523
Download (untitled) / with headers
text/plain 2.4k
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
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-11061-1284189609-948.56225-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-11057-1284140667-501.56225-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-11057-1284142663-271.56225-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-11059-1284149868-132.56225-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-11061-1284189609-948.56225-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-11064-1284192274-524.56225-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
From: Garen
X-RT-Original-Encoding: utf-8
Content-Length: 3092
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
From nick [...] flirble.org Sat Sep 11 14: 11:10 2010
CC: jpl [...] plosquare.com, perl5-porters [...] perl.org
MIME-Version: 1.0
X-Spam-Status: No, score=-6.319 tagged_above=-99.9 required=10 tests=[AWL=3.594, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SPF_NEUTRAL=0.686] autolearn=ham
In-Reply-To: <rt-3.8.HEAD-11064-1284192275-114.56225-6-0 [...] rt.cpan.org>
Content-Disposition: inline
X-Spam-Flag: NO
X-Organisation: Tetrachloromethane
References: <RT-Ticket-56225 [...] rt.cpan.org> <rt-3.8.HEAD-11057-1284140667-501.56225-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-11057-1284142663-271.56225-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-11059-1284149868-132.56225-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-11061-1284189609-948.56225-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-11064-1284192275-114.56225-6-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <20100911181355.GU48531 [...] plum.flirble.org>
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -6.319
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id B2048240CAC for <cpan-bug+PathTools [...] hipster.bestpractical.com>; Sat, 11 Sep 2010 14:11:10 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OurdOnS-ULwi for <cpan-bug+PathTools [...] hipster.bestpractical.com>; Sat, 11 Sep 2010 14:11:08 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 29174240C90 for <bug-PathTools [...] rt.cpan.org>; Sat, 11 Sep 2010 14:11:07 -0400 (EDT)
Received: (qmail 28635 invoked by uid 103); 11 Sep 2010 18:14:01 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 11 Sep 2010 18:14:01 -0000
Received: from plum.flirble.org (HELO plum.flirble.org) (195.99.220.128) by 16.mx.develooper.com (qpsmtpd/0.80) with ESMTP; Sat, 11 Sep 2010 11:13:59 -0700
Received: from nick by plum.flirble.org with local (Exim 4.69 (FreeBSD)) (envelope-from <nick [...] flirble.org>) id 1OuUaJ-000Bms-Ia; Sat, 11 Sep 2010 19:13:55 +0100
Delivered-To: cpan-bug+PathTools [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #56225] Innocent-looking Cwd change breaks EPIC + debugger on win32
User-Agent: Mutt/1.4.2.3i
Return-Path: <nick [...] flirble.org>
X-Spam-Check-BY: 16.mx.develooper.com
X-Original-To: cpan-bug+PathTools [...] hipster.bestpractical.com
X-RT-Mail-Extension: pathtools
Date: Sat, 11 Sep 2010 19:13:55 +0100
Sender: Nicholas Clark <nick [...] flirble.org>
X-Spam-Level:
To: "https://www.google.com/accounts/o8/id?id=AItOawn_DiEb3KC_WyL1eDoRstaKxFknWBpUgiw via RT" <bug-PathTools [...] rt.cpan.org>
Mail-Followup-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
From: Nicholas Clark <nick [...] ccl4.org>
RT-Message-ID: <rt-3.8.HEAD-11059-1284228844-858.56225-0-0 [...] rt.cpan.org>
Content-Length: 2039
Download (untitled) / with headers
text/plain 1.9k
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
From rgarciasuarez [...] gmail.com Sat Sep 11 16: 13:12 2010
CC: jpl [...] plosquare.com, perl5-porters [...] perl.org
MIME-Version: 1.0
X-Spam-Status: No, score=-6.256 tagged_above=-99.9 required=10 tests=[AWL=3.657, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SPF_NEUTRAL=0.686] autolearn=ham
In-Reply-To: <rt-3.8.HEAD-11061-1284189611-290.56225-6-0 [...] rt.cpan.org>
X-Spam-Flag: NO
References: <RT-Ticket-56225 [...] rt.cpan.org> <rt-3.8.HEAD-11057-1284140667-501.56225-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-11057-1284142663-271.56225-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-11059-1284149868-132.56225-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-11061-1284189611-290.56225-6-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <AANLkTikNx6+pMHHnYuK7+cFnx8GxP2z_nMntz2AwoHK9 [...] mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -6.256
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] gmail.com
Authentication-Results: hipster.bestpractical.com (amavisd-new); domainkeys=pass header.sender=rgarciasuarez [...] gmail.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 36C8A240CB3 for <cpan-bug+PathTools [...] hipster.bestpractical.com>; Sat, 11 Sep 2010 16:13:12 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dISZVHmJgvd3 for <cpan-bug+PathTools [...] hipster.bestpractical.com>; Sat, 11 Sep 2010 16:13:10 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id BA30E240CAC for <bug-PathTools [...] rt.cpan.org>; Sat, 11 Sep 2010 16:13:09 -0400 (EDT)
Received: (qmail 8173 invoked by uid 103); 11 Sep 2010 20:16:02 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 11 Sep 2010 20:16:02 -0000
Received: from mail-iw0-f178.google.com (HELO mail-iw0-f178.google.com) (209.85.214.178) by 16.mx.develooper.com (qpsmtpd/0.80) with ESMTP; Sat, 11 Sep 2010 13:16:01 -0700
Received: by iwn35 with SMTP id 35so3348502iwn.9 for <bug-PathTools [...] rt.cpan.org>; Sat, 11 Sep 2010 13:15:58 -0700 (PDT)
Received: by 10.231.35.77 with SMTP id o13mr3246648ibd.92.1284236158225; Sat, 11 Sep 2010 13:15:58 -0700 (PDT)
Received: by 10.231.199.79 with HTTP; Sat, 11 Sep 2010 13:15:58 -0700 (PDT)
Delivered-To: cpan-bug+PathTools [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #56225] Innocent-looking Cwd change breaks EPIC + debugger on win32
Domainkey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=BRWcOlieC6KRzO4GvEG/Rf5IObFAq8LTNhCK8poGKvPwgoDXKIvjeMCw2EysRuQYqs TbmTLQguMyIJPg4vd71yaJ3HQt9iyX7IbvcCVTyCRC0gnRuQtMQuahcyJhSQ3wTrxBGx LqTg4JtN5iz9sx4U7z+rbuVeBkwRG2327rb1U=
Return-Path: <rgarciasuarez [...] gmail.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=AUV/ixXasjwGcKBHomI342ep04xJfX558kDAIpC/MUc=; b=BRUXndswutkS+fnn8yyZO0IYxD+S1Zjrarld7r+sb30S0dr79qtSOu/n23/S6CD28M XnUgCeawO7ySUchcSTlmAjZmjsxU6l2eKJ8jU+8UhAEGhlPvNoymrQV061KV/0dZtmBS I/xxHrBmJjQPoKmceGFHUGGB+/2lG6XA6aANE=
X-Spam-Check-BY: 16.mx.develooper.com
X-Original-To: cpan-bug+PathTools [...] hipster.bestpractical.com
X-RT-Mail-Extension: pathtools
X-Google-Sender-Auth: 6ZnKX8mKCIU4dBx4ZU2vN1j0aEg
Sender: rgarciasuarez [...] gmail.com
Date: Sat, 11 Sep 2010 22:15:58 +0200
X-Spam-Level:
To: bug-PathTools [...] rt.cpan.org
From: Rafael Garcia-Suarez <rgs [...] consttype.org>
RT-Message-ID: <rt-3.8.HEAD-11060-1284236167-660.56225-0-0 [...] rt.cpan.org>
Content-Length: 423
Download (untitled) / with headers
text/plain 423b
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 ?
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-11060-1284236167-660.56225-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <RT-Ticket-56225 [...] rt.cpan.org> <rt-3.8.HEAD-11057-1284140667-501.56225-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-11057-1284142663-271.56225-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-11059-1284149868-132.56225-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-11061-1284189611-290.56225-6-0 [...] rt.cpan.org> <AANLkTikNx6+pMHHnYuK7+cFnx8GxP2z_nMntz2AwoHK9 [...] mail.gmail.com> <rt-3.8.HEAD-11060-1284236167-660.56225-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-11060-1284239280-1565.56225-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
From: jpl [...] plosquare.com
X-RT-Original-Encoding: utf-8
Content-Length: 3318
Download (untitled) / with headers
text/plain 3.2k
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 ?
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-11060-1284239280-1565.56225-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <RT-Ticket-56225 [...] rt.cpan.org> <rt-3.8.HEAD-11057-1284140667-501.56225-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-11057-1284142663-271.56225-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-11059-1284149868-132.56225-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-11061-1284189611-290.56225-6-0 [...] rt.cpan.org> <AANLkTikNx6+pMHHnYuK7+cFnx8GxP2z_nMntz2AwoHK9 [...] mail.gmail.com> <rt-3.8.HEAD-11060-1284236167-660.56225-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-11060-1284239280-1565.56225-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-24883-1284876014-850.56225-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
From: Garen
X-RT-Original-Encoding: utf-8
Content-Length: 4344
Download (untitled) / with headers
text/plain 4.2k
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.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-18810-1308326886-1924.56225-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
From: vvm [...] tut.by
X-RT-Original-Encoding: utf-8
Content-Length: 788
Download (untitled) / with headers
text/plain 788b
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) { ==
From reini.urban [...] gmail.com Sat Jun 18 06: 08:15 2011
CC: jpl [...] plosquare.com, perl5-porters [...] perl.org
MIME-Version: 1.0
X-Spam-Status: No, score=-5.775 tagged_above=-99.9 required=10 tests=[AWL=0.334, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RFC_ABUSE_POST=0.001, SPF_NEUTRAL=0.779, T_TO_NO_BRKTS_FREEMAIL=0.01] autolearn=ham
In-Reply-To: <rt-3.8.HEAD-18810-1308326887-1574.56225-6-0 [...] rt.cpan.org>
X-Spam-Flag: NO
References: <RT-Ticket-56225 [...] rt.cpan.org> <rt-3.8.HEAD-18810-1308326887-1574.56225-6-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <BANLkTimexaAa71J=36AvktzEu2C5Y8EFQg [...] mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -5.775
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] gmail.com
Authentication-Results: hipster.bestpractical.com (amavisd-new); domainkeys=pass header.sender=reini.urban [...] gmail.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id B22D7240390 for <cpan-bug+PathTools [...] hipster.bestpractical.com>; Sat, 18 Jun 2011 06:08:15 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5unuAJkWjXOH for <cpan-bug+PathTools [...] hipster.bestpractical.com>; Sat, 18 Jun 2011 06:08:14 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id AD394240364 for <bug-PathTools [...] rt.cpan.org>; Sat, 18 Jun 2011 06:08:13 -0400 (EDT)
Received: (qmail 6682 invoked by uid 103); 18 Jun 2011 10:08:13 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 18 Jun 2011 10:08:13 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com) (209.85.216.171) by 16.mx.develooper.com (qpsmtpd/0.80/v0.80-19-gf52d165) with ESMTP; Sat, 18 Jun 2011 03:08:10 -0700
Received: by qyl38 with SMTP id 38so829921qyl.9 for <bug-PathTools [...] rt.cpan.org>; Sat, 18 Jun 2011 03:08:07 -0700 (PDT)
Received: by 10.229.131.32 with SMTP id v32mr2548079qcs.35.1308391687166; Sat, 18 Jun 2011 03:08:07 -0700 (PDT)
Received: by 10.229.202.170 with HTTP; Sat, 18 Jun 2011 03:08:07 -0700 (PDT)
Delivered-To: cpan-bug+PathTools [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #56225] Innocent-looking Cwd change breaks EPIC + debugger on win32
Domainkey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EcEpxQqGqn0SaoHPI2rEUSqf6cwpnXiZOTDJkmR3483LX2pF5dKDiqMdDazg7gm0iJ uhzCxGSPwAHOJxQlG+F3yqyzt5wavkitYc8jAmyt/RQ1vK4tKHSvfw3TOIowXMafO/Zw zk4nijLXCf9UP5U/rkcK+AYuJuimUGsV+rtm4=
Return-Path: <reini.urban [...] gmail.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=you2z5JfvuEKDJ+rSuC7i2hA6vpJv7KThae2O7cCp0o=; b=E3x6Ef7fCk7S39nZ8KS0K/3/iY/+S4BuxvOsxPdZA81dxqKOzBN4PCChplQ1bA1Inl 3AYefNgqtFb7lT0EQ5aQHkWrdTRzc3jE4zJPiQiYnye2AcIgXkTL5jwAdcLcL6GZJ6Yi 1RJrfMEQ531mJAYqkZBPBKO08FbQQcc+aIUQg=
X-Spam-Check-BY: 16.mx.develooper.com
X-Original-To: cpan-bug+PathTools [...] hipster.bestpractical.com
X-RT-Mail-Extension: pathtools
X-Google-Sender-Auth: sRkNAq_xYTvTjJrpiDfoN1ls-uQ
Sender: reini.urban [...] gmail.com
Date: Sat, 18 Jun 2011 05:08:07 -0500
X-Spam-Level:
To: bug-PathTools [...] rt.cpan.org
Content-Transfer-Encoding: quoted-printable
From: Reini Urban <rurban [...] x-ray.at>
RT-Message-ID: <rt-3.8.HEAD-18808-1308391696-1160.56225-0-0 [...] rt.cpan.org>
Content-Length: 1191
Download (untitled) / with headers
text/plain 1.1k
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
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-18808-1308391696-1160.56225-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <RT-Ticket-56225 [...] rt.cpan.org> <rt-3.8.HEAD-18810-1308326887-1574.56225-6-0 [...] rt.cpan.org> <BANLkTimexaAa71J=36AvktzEu2C5Y8EFQg [...] mail.gmail.com> <rt-3.8.HEAD-18808-1308391696-1160.56225-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-18805-1308581180-480.56225-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
From: vvm [...] tut.by
X-RT-Original-Encoding: utf-8
Content-Length: 332
Download (untitled) / with headers
text/plain 332b
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} ) { ==
From nick [...] flirble.org Thu Jul 7 09: 55:48 2011
MIME-Version: 1.0
X-Spam-Status: No, score=-3.985 tagged_above=-99.9 required=10 tests=[AWL=0.650, BAYES_00=-1.9, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779] autolearn=ham
In-Reply-To: <rt-3.8.HEAD-18805-1308581181-1090.56225-6-0 [...] rt.cpan.org> <BANLkTimexaAa71J=36AvktzEu2C5Y8EFQg [...] mail.gmail.com> <20100911181355.GU48531 [...] plum.flirble.org>
Content-Disposition: inline
X-Spam-Flag: NO
X-Organisation: Tetrachloromethane
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <20110707135536.GO23881 [...] plum.flirble.org>
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -3.985
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 38787240476 for <cpan-bug+PathTools [...] hipster.bestpractical.com>; Thu, 7 Jul 2011 09:55:48 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjXgm+ijnmxL for <cpan-bug+PathTools [...] hipster.bestpractical.com>; Thu, 7 Jul 2011 09:55:46 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 923B0240440 for <bug-PathTools [...] rt.cpan.org>; Thu, 7 Jul 2011 09:55:45 -0400 (EDT)
Received: (qmail 6070 invoked by uid 103); 7 Jul 2011 13:55:44 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 7 Jul 2011 13:55:44 -0000
Received: from plum.flirble.org (HELO plum.flirble.org) (195.99.220.128) by 16.mx.develooper.com (qpsmtpd/0.80/v0.80-19-gf52d165) with ESMTP; Thu, 07 Jul 2011 06:55:41 -0700
Received: from nick by plum.flirble.org with local (Exim 4.75 (FreeBSD)) (envelope-from <nick [...] flirble.org>) id 1Qep3I-0009xG-Jn; Thu, 07 Jul 2011 14:55:36 +0100
Delivered-To: cpan-bug+PathTools [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #56225] Innocent-looking Cwd change breaks EPIC + debugger on win32
User-Agent: Mutt/1.5.21 (2010-09-15)
Return-Path: <nick [...] flirble.org>
X-Spam-Check-BY: 16.mx.develooper.com
X-Original-To: cpan-bug+PathTools [...] hipster.bestpractical.com
X-RT-Mail-Extension: pathtools
Date: Thu, 7 Jul 2011 14:55:36 +0100
Sender: Nicholas Clark <nick [...] flirble.org>
X-Spam-Level:
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>
RT-Message-ID: <rt-3.8.HEAD-9060-1310046949-838.56225-0-0 [...] rt.cpan.org>
Content-Length: 3427
Download (untitled) / with headers
text/plain 3.3k
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
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-9060-1310046949-838.56225-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-3.8.HEAD-18805-1308581181-1090.56225-6-0 [...] rt.cpan.org> <BANLkTimexaAa71J=36AvktzEu2C5Y8EFQg [...] mail.gmail.com> <20100911181355.GU48531 [...] plum.flirble.org> <20110707135536.GO23881 [...] plum.flirble.org> <rt-3.8.HEAD-9060-1310046949-838.56225-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-24862-1385309054-1693.56225-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 3869
Download (untitled) / with headers
text/plain 3.7k
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.