Re: kill mv-if-diff?
On Sat, Sep 24, 2005 at 04:31:45PM +0100, Nicholas Clark wrote: The distribution contains a shell script mv-if-diff, which does what it says. The Makefile uses it to avoid touching the timestamps on automatically generated files, if they've not actually changed. For example, lib/Config.pm I notice that on my local checkout of maint, when I do a clean rebuild, lib/unicore/mktables is being run 7 times. I also observe that sometimes when I edit files and rebuild, later files needlessly get rebuilt, probably because make thinks something is out of date, something that never gets updated, probably because it's not being touched, due to mv-if-diff, and there are non-file targets in the dependency tree. Parallel makes are also broken. I wonder if all this is related. Should we just get rid of mv-if-diff, and let make be the sole arbiter of what needs updating? And trust that if make wants to rebuild something, it should. I think that doing this would make our rebuilds cleaner, and make it easier to work out the correct set of dependencies such that we can make parallel makes work. I had fixed one bug with parallel make that was somewhat effected by mv-if-diff, but the biggest issue was just having correct dependencies in the Makefile. My thoughts are that mv-if-diff is just a symptom of a different problem in the Makefile where more targets and dependencies are needed. Steve Peters [EMAIL PROTECTED]
Re: Smoke [5.8.7] 25589 FAIL(m) MSWin32 WinXP/.Net SP2 (x86/2 cpu)
On Sat, Sep 24, 2005 at 12:45:35PM +0100, Nicholas Clark wrote: On Fri, Sep 23, 2005 at 09:14:09PM +0100, Nicholas Clark wrote: And between last time and this one I didn't think that there were any dangerous changes. Given that, and the lack of any helpful log on this smoke report, I'm stuck as to what I messed up that needs fixing. I think I failed to spot a change that I needed to integrate. Hopefully 25592 fixes it. I think that Steve Hay's 5.8.7 smoker only works weekdays, so if someone else is able to test build maint on Windows I'd be most grateful. I pulled down a perl-5.8.x at 25596, and it built just fine on Win32. There does seem to be a bit of a problem with the Win32 Makefile, though. Several files are getting getting compiled twice. What happens is all the files that do not dependin on the Win32 config.h are built. conofig.h is created and the rest of the core files are built. Then, config.h is recreated forcing a recompile of all the files that depend on config.h. Steve Peters [EMAIL PROTECTED]
[PATCH] Changes for hints/linux.sh for Purify
Purify's ld is much more picky regarding duplicate symbols than the GNU ld. It automatically includes libc by default. Configure, however, includes a -lc when linking, causing the link to fail. The following patch deals with the duplicate symbols by removing libc from the libraries that Configure will probe for when it is run with a -DPURIFY argument. Steve Peters [EMAIL PROTECTED] --- hints/linux.sh.old 2005-08-18 09:17:47.0 -0500 +++ hints/linux.sh 2005-09-23 08:38:08.0 -0500 @@ -315,3 +315,13 @@ ;; esac EOCBU + +# Purify fails to link Perl if a -lc is passed into its linker +# due to duplicate symbols. +case $PURIFY in +$define|true|[yY]*) +set `echo X $libswanted | sed -e 's/ c / /'` +shift +libswanted=$* +;; +esac
[PATCH] Fix to PERL_DEBUG_COW
Change #25571 has caused the smokes to be broken when building with -DPERL_DEBUG_COW. The following patch fixes the builds. Steve Peters [EMAIL PROTECTED] --- sv.h.old2005-09-22 10:02:52.0 -0500 +++ sv.h2005-09-23 13:05:24.0 -0500 @@ -887,11 +887,6 @@ # define SvLEN(sv) ((XPV*) SvANY(sv))-xpv_len # define SvEND(sv) ((sv)-sv_u.svu_pv + ((XPV*)SvANY(sv))-xpv_cur) -/* Given that these two are new, there can't be any existing code using them - * as LVALUEs */ -#define SvPVX_mutable(sv) (0 + (sv)-sv_u.svu_pv) -#define SvPVX_const(sv)((const char*)(0 + (sv)-sv_u.svu_pv)) - # ifdef DEBUGGING #define SvMAGIC(sv)(*(assert(SvTYPE(sv) = SVt_PVMG), ((XPVMG*) SvANY(sv))-xmg_magic)) #define SvSTASH(sv)(*(assert(SvTYPE(sv) = SVt_PVMG), ((XPVMG*) SvANY(sv))-xmg_stash)) @@ -901,6 +896,11 @@ # endif #endif +/* Given that these two are new, there can't be any existing code using them + * * as LVALUEs */ +#define SvPVX_mutable(sv) (0 + (sv)-sv_u.svu_pv) +#define SvPVX_const(sv) ((const char*)(0 + (sv)-sv_u.svu_pv)) + #define SvIVXx(sv) SvIVX(sv) #define SvUVXx(sv) SvUVX(sv) #define SvNVXx(sv) SvNVX(sv)
Re: [perl #37223] File::Find::find fails on Win32 with follow = 1
On Wed, Sep 21, 2005 at 04:57:31PM +0200, Rafael Garcia-Suarez wrote: Steve Hay (via RT) wrote: The File::Find::find() function fails on Win32 if the follow = 1 option is specified. Presumably follow (and follow_fast?) should be no-ops on Win32 since symbolic links are not supported on that OS. Seems quite sensible. Is this a new problem ? I can't believe nobody noticed it until now... If its new, then I'm probably the one who broke it. Can you see which versions that it is now broken on? Or did it just hit another bug previously. Steve Peters [EMAIL PROTECTED]
Re: [perl #37223] File::Find::find fails on Win32 with follow = 1
On Wed, Sep 21, 2005 at 10:29:25AM -0500, Steve Peters wrote: On Wed, Sep 21, 2005 at 04:57:31PM +0200, Rafael Garcia-Suarez wrote: Steve Hay (via RT) wrote: The File::Find::find() function fails on Win32 if the follow = 1 option is specified. Presumably follow (and follow_fast?) should be no-ops on Win32 since symbolic links are not supported on that OS. Seems quite sensible. Is this a new problem ? I can't believe nobody noticed it until now... If its new, then I'm probably the one who broke it. Can you see which versions that it is now broken on? Or did it just hit another bug previously. Steve Peters [EMAIL PROTECTED] OK, it looks like there might be a problem with change #23510. I'll take a look at it when I have a little more time this evening. Steve Peters [EMAIL PROTECTED]
Re: Smoke [5.8.7] 25531 FAIL(F) openbsd 3.7 (i386/1 cpu)
On Wed, Sep 21, 2005 at 06:52:00PM -0500, [EMAIL PROTECTED] wrote: Automated smoke report for 5.8.7 patch 25531 mccoy.peters.homeunix.org: Intel Pentium III (GenuineIntel 686-class, 512KB L2 cache) (i386/1 cpu) onopenbsd - 3.7 using cc version 3.3.5 (propolice) smoketime 10 hours 43 minutes (average 1 hour 4 minutes) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25531 Configuration (common) none --- - F - F - -Uuseperlio F F F F F F F F -Duse64bitint F F F F -Duseithreads F F F F -Duseithreads -Duse64bitint | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: [stdio] -Uuseperlio ../lib/filetest.t...FAILED 12-15 Inconsistent test results (between TEST and harness): ../ext/B/t/xref.t...FAILED--expected 14 tests, saw 2 Both sets of failures should be resolved by patches integrated into maintperl today. Steve Peters [EMAIL PROTECTED]
Re: [EMAIL PROTECTED] VMS fix required by Change 25387
On Sun, Sep 18, 2005 at 09:04:34PM +0200, H.Merijn Brand wrote: On Sun, 18 Sep 2005 14:53:09 -0400, John E. Malmberg [EMAIL PROTECTED] wrote: Two config parameters were added to Configure so they also need to be added to configure.com. VMS does not have those functions. ooh man, do I feel guilty! Thanks, applied as change #25474 Any win32 people that can test for the win32env? -John [EMAIL PROTECTED] Personal Opinion Only I've not had any problems with Win32 today, but I don't normally build on it. Steve Peters [EMAIL PROTECTED]
Re: [perl #37168] Bug in HTTP::Message-parse()
On Wed, Sep 14, 2005 at 07:06:36AM -0700, [EMAIL PROTECTED] (via RT) wrote: # New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #37168] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37168 This is a bug report for perl from julien23.free.fr, generated with the help of perlbug 1.35 running under perl v5.8.7. - [Please enter your report here] The parse() function of the HTTP::Message library fails to parse some files due to a wrong pattern matching during header parsing. Example message (ignore first line before parsing): http://julien23.free.fr/pub/patches/HTTP::Message_parse_error.http Example decoder: http://julien23.free.fr/pub/patches/HTTP::Message_parse_error.pl Patch: http://julien23.free.fr/pub/patches/patch_Perl_HTTP::Message_parse.diff Unfortunately, we do not support the HTTP::Message module, just the core Perl package. Looking at http://rt.cpan.org/NoAuth/Bugs.html?Dist=libwww-perl a similar bug has already been reported, although no patch had been previously provided. I'd suggest adding on the the bug report available at: http://rt.cpan.org/NoAuth/Bug.html?id=13025 Steve Peters [EMAIL PROTECTED]
[perl #36075] Adding malloc_size/malloc_good_size to Configure
[nicholas - Wed Jun 01 08:09:31 2005]: This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.35 running under perl v5.9.3. - [Please enter your report here] Darwin provides 2 extra malloc() functions: The malloc_size() function returns the size of the memory block that backs the allocation pointed to by ptr. The memory block size is always at least as large as the allocation it backs, and may be larger. The malloc_good_size() function rounds size up to a value that the allo- cator implementation can allocate without adding any padding and returns that rounded up value. It's not clear if any other malloc implementations provide these functions, or the same functionality with another name, apart from Perl's own malloc's malloced_size It would be useful to probe for them, because if they either are found it would allow efficiency savings in various places. Specifically when buffers allocated for SvPVX() we could set SvLEN() to the true maximum length, and AV storage extension could be tuned to use all the memory malloc() actually gave us. The detection was added to Configure with change #25387. Now, just wait for someone to make good use of it.
Re: Storable 2.15 on OSX 10.4 with maintperl fails make test
On Wed, Sep 14, 2005 at 10:07:42AM -0700, Randal L. Schwartz wrote: t/weakWeak references are not implemented in the version of perl at t/weak.t line 28 BEGIN failed--compilation aborted at t/weak.t line 33. t/weakdubious Test returned status 255 (wstat 65280, 0xff00) Huh? Since when are Weak references not implemented in modern Perls? I've seen this issue elsewhere but haven't caught whether the problem is with the default Perl installed on OS X 10.4, or if this is a freshly built maint. Which are you seeing this on? The actually cause of the problem lies in how Scalar::Utils is built. The implementation you have was built without compiling the XS portion of Scalar::Utils. If you do a fresh install of Scalar::Utils, the problems are fixed. Steve Peters [EMAIL PROTECTED]
Re: [perl #32884] API doc for SvUTF8
On Mon, Sep 12, 2005 at 12:41:23PM +0200, Rafael Garcia-Suarez wrote: Steve Peters via RT wrote: Acutally, everything looking a return value from SvFLAGS(sv) should be looking for a U32. Since I'd like to automate these changes as much as possible, how does the following look? Fine, but probably all other docs for SvFLAGS bit tests need the same change, no ? Yes, they do. They have nearly identical API doc listings, though, so this is just the sample change.
Re: 5.8.8
On Mon, Sep 12, 2005 at 05:29:39PM +0100, Nicholas Clark wrote: If there's a plan for 5.8.8, it goes roughly like this 0: All changes that apply to maint are integrated from blead 1: Changes should be in blead by midnight (GMT) on the 16th October 2005 2: RC1 will probably appear within a week I'll be out of the country for the first week in October, and probably mostly incommunicado. I'll be in the country for the second week, but again mostly incommunicado. This definitely isn't a problem, as a: how patches get into blead *isn't* my direct concern b: stable stuff isn't done as a last minute rush job [You may read this as if not being able to get patches into maint at the last minute worries you, then those patches will by definition worry me] Clearly if anyone wants to fix bugs in pseudohashes or 5005 threads, then those patches have to go direct to maint. But I believe that little else does. The only other exception would be changes to re-entrant functions through reentr.pl, where the generated code is quite different than that in bleadperl. Steve Peters [EMAIL PROTECTED]
[perl #36075] Adding malloc_size/malloc_good_size to Configure
[nicholas - Wed Jun 01 08:09:31 2005]: This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.35 running under perl v5.9.3. - [Please enter your report here] Darwin provides 2 extra malloc() functions: The malloc_size() function returns the size of the memory block that backs the allocation pointed to by ptr. The memory block size is always at least as large as the allocation it backs, and may be larger. The malloc_good_size() function rounds size up to a value that the allo- cator implementation can allocate without adding any padding and returns that rounded up value. It's not clear if any other malloc implementations provide these functions, or the same functionality with another name, apart from Perl's own malloc's malloced_size It would be useful to probe for them, because if they either are found it would allow efficiency savings in various places. Specifically when buffers allocated for SvPVX() we could set SvLEN() to the true maximum length, and AV storage extension could be tuned to use all the memory malloc() actually gave us. Adding the detection for these function is pretty simple, and Configure doesn't need to do anything more that standard libc scanning. I'm guessing it would be easy to add to Metaconfig to check. The following patches can do it for playing with, but don't apply to p4. Merijn, do you need any more information for the Metaconfig changes? --- Configure.old Tue Sep 6 09:38:43 2005 +++ Configure Sat Sep 10 19:44:50 2005 @@ -550,6 +550,8 @@ d_lseekproto='' d_lstat='' d_madvise='' +d_malloc_size='' +d_malloc_good_size='' d_mblen='' d_mbstowcs='' d_mbtowc='' @@ -14247,6 +14249,14 @@ set madvise d_madvise eval $inlibc +: see if malloc_size exists +set malloc_size d_malloc_size +eval $inlibc + +: see if malloc_size_good exists +set malloc_good_size d_malloc_good_size +eval $inlibc + : see if mblen exists set mblen d_mblen eval $inlibc @@ -21112,6 +21122,8 @@ d_lseekproto='$d_lseekproto' d_lstat='$d_lstat' d_madvise='$d_madvise' +d_malloc_size='$d_malloc_size' +d_malloc_size_good='$d_malloc_size_good' d_mblen='$d_mblen' d_mbstowcs='$d_mbstowcs' d_mbtowc='$d_mbtowc' --- config_h.SH.old Tue Jun 21 14:56:18 2005 +++ config_h.SH Sat Sep 10 19:22:05 2005 @@ -3889,6 +3889,18 @@ */ #$d_libm_lib_version LIBM_LIB_VERSION /**/ +/* HAS_MALLOC_SIZE + * This symbol, if defined, indicates that the malloc_size + * routine is available for use. + */ +#$d_malloc_size HAS_MALLOC_SIZE /**/ + +/* HAS_MALLOC_GOOD_SIZE + * This symbol, if defined, indicates that the malloc_good_size + * routine is available for use. + */ +#$d_malloc_good_size HAS_MALLOC_GOOD_SIZE /**/ + /* HAS_NL_LANGINFO: * This symbol, if defined, indicates that the nl_langinfo routine is * available to return local data. You will also need langinfo.h
[perl #32884] API doc for SvUTF8
[EMAIL PROTECTED] - Sun Dec 05 18:25:51 2004]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.4.
-
[Please enter your report here]
The doc for SvUTF8 says:
SvUTF8 Returns a boolean indicating whether the SV contains
UTF-8
encoded data.
boolSvUTF8(SV* sv)
The code however does:
#define SvUTF8(sv) (SvFLAGS(sv) SVf_UTF8)
which results in an U32
That is of course no problem in constructs like:
if (SvUTF8(sv)) { ... }
but if you do:
bool utf8 = SvUTF8(sv);
...
if (utf8) { ... }
things fail badly because (at least on my system) the bool enum
becomes a
char, and since SVf_UTF8 is 0x2000, utf8 will always be 0 after
truncate.
Either the docs or the macro should be updated I think
Several other things that are called bool in the api doc have the
same
problem (e.g. SvIOK, SvIOKp, SvPOK, etc)
Acutally, everything looking a return value from SvFLAGS(sv) should be
looking for a U32. Since I'd like to automate these changes as much
as possible, how does the following look?
--- sv.h.oldSat Sep 10 20:30:54 2005
+++ sv.hSat Sep 10 20:30:47 2005
@@ -703,8 +703,8 @@
SvFLAGS(sv) |= (SVf_NOK|SVp_NOK))
/*
-=for apidoc Am|bool|SvUTF8|SV* sv
-Returns a boolean indicating whether the SV contains UTF-8 encoded data.
+=for apidoc Am|U32l|SvUTF8|SV* sv
+Returns a U32 value indicating whether the SV contains UTF-8 encoded data.
=for apidoc Am|void|SvUTF8_on|SV *sv
Turn on the UTF-8 status of an SV (the data is not changed, just the flag).
There will probably need to be some changes in the core as well where
any of Sv*OK-like macros are on the right side of an assignment.
[perl #36448] [PATCH] configuring ranlib for perl on osx with xcode 2.1
[EMAIL PROTECTED] - Fri Jul 01 14:56:29 2005]: Hello, It looks like Apple has changed how ar works in xcode 2.1. As a result, Configure thinks that ar can generate random libraries. This breaks linking libperl.a, for instance when building PerlApp. Configure doesn't currently allow overriding ranlib when Configure detects that ranlib isn't necessary. My patch fixes this, and sets ranlib for darwin. Note that this patch is for ActivePerl 5.6.1 (it doesn't appear to be fixed in 5.9.2), so it probably needs to be manually applied... Configure 13888c13888,13890 ranlib=: --- if [ X$ranlib = X ]; then ranlib=: fi hints/darwin.sh 179a180,183 # Configure doesn't detect ranlib on Tiger properly. # NeilW says this should be acceptable on all darwin versions. ranlib='ranlib' Luke Has anyone looked at this patch yet? I'm assuming that since it was written against 5.6.1 rather than the current bleadperl and it isn't in diff -u format, a new patch might be needed. One question comes to mind when I look at it, though. Have you tested the patch on a non-Tiger system?
[perl #35427] reset coredumps pre 5.8.0
[nicholas - Thu May 12 14:52:46 2005]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.6.2.
-
[Please enter your report here]
/Users/nick/Reference/5.6.2-g/bin/perl5.6.2-32 -MData::Dumper -e
'package Data::Dumper; reset'
Bus error
(gdb) where
#0 0x0005a1d8 in Perl_sv_reset (s=0x129570 , stash=0x806fe0) at
sv.c:5063
#1 0x000ad534 in Perl_pp_reset () at pp_ctl.c:1631
#2 0x000dd590 in Perl_runops_debug () at run.c:53
#3 0x0002114c in S_run_body (oldscope=1) at perl.c:1471
#4 0x00020a74 in perl_run (my_perl=0x300140) at perl.c:1393
#5 0x1c5c in main (argc=4, argv=0xb6c4, env=0xb6d8) at
perlmain.c:52
Line 5063 is the middle line of:
if (!*s) {/* reset ?? searches */
for (pm = HvPMROOT(stash); pm; pm = pm-op_pmnext) {
pm-op_pmdynflags = ~PMdf_USED;
}
return;
}
I'm not convinced that gdb has the correct value of pm. It seems to
have
pm for the second iteration:
(gdb) p pm
$7 = (PMOP *) 0xa7f2c
(gdb) p stash-sv_any-xhv_pmroot
$8 = (PMOP *) 0x336470
(gdb) p stash-sv_any-xhv_pmroot-op_pmnext
$9 = (PMOP *) 0xa7f2c
However, the cause of the bus error is clear:
(gdb) p *pm-op_pmnext
$10 = {
op_next = 0x7f9a,
op_sibling = 0x40be0014,
op_ppaddr = 0x3c9f0ffe,
op_targ = 945815552,
op_type = 14468,
op_seq = 18156,
op_flags = 72 'H',
op_private = 5 '\005',
op_first = 0x3c000800,
op_last = 0x6100,
op_pmreplroot = 0x7f9a,
op_pmreplstart = 0x40be005c,
op_pmnext = 0x7f83e378,
op_pmregexp = 0x4bff34ad,
op_pmflags = 31869,
op_pmpermflags = 7032,
op_pmdynflags = 127 '\177'
}
(gdb) p *pm-op_pmnext-op_pmnext
Cannot access memory at address 0x7f83e378
And my question, which I fear will be Warnocked - do we know what
change
caused this bug to be fixed by 5.8.0?
Or can anyone reproduce it in 5.8.0 or later?
Nicholas Clark
It is working fine in 5.5-maint.
[EMAIL PROTECTED]:~/perl-5.5.x$ ./perl -Ilib -MData::Dumper -e 'package
Data::Dumper; reset'
[EMAIL PROTECTED]:~/perl-5.5.x$
[perl #32154] getXXXent functions break after recursing to grow buffer
[EMAIL PROTECTED] - Tue Nov 02 16:25:47 2004]: On Tue, 2004-11-02 at 14:56, Nicholas Clark wrote: ftp://ftp.linux.activestate.com/pub/staff/gsar/APC/perl-5.8.x/ ftp://ftp.linux.activestate.com/pub/staff/gsar/APC/perl-current/ Other than comments, there is no difference between reentr.* at the 5.8.x URL and that in the broken 5.8.3-18 in Fedora Core 2. perl-current source is organized differently but the relevant code seems to be the same (reentr.c line 694). It erroneously assumes that errno is meaningful. The obvious fix is to remove the || (errno == ERANGE) clause. However, there may be other libraries out there with different definitions of getXXXent_r. Note that the getXXXent_r functions can be rather complicated, searching not just /etc/group but optionally NIS too under contro of nsswitch.conf. They may execute a large number of system calls so errno may be clobbered many times (or not at all). Hence the need to only check the return value. This problem has been fixed with change 25084.
[perl #37056] getgrent fails if a line in /etc/groups gets too long
[michielblotwijk - Fri Sep 02 06:53:56 2005]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.5.
-
[Please enter your report here]
The function getgrent throws an error if a line in /etc/groups gets
too long ( 3000 characters). This error can be reproduced as follows:
1/ Manually add a large number of users to a group in /etc/group. It
doesn't
really matter if these are real users or not, as long as the line
exceeds
3000 characters.
2/ perl -e 'use User::grent; while (my $gr = getgrent() ) { print
$gr-name.\n; }'
This will return an Out of memory! message.
This thread seems to be related:
http://lists.debian.org/debian-security/2005/06/msg00041.html
The issue mentioned on the Debian lists is indeed the problem. The fix
suggested was implemented in change #25084.
[perl #8907] Core dump on HP-UX using getpwent.
[stmpeters - Tue Dec 07 16:53:42 2004]:
[abigail - Thu Apr 04 01:07:36 2002]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.33 running under perl v5.6.1.
-
[Please enter your report here]
While teaching a Perl course at HP, one of the students pointed out
running a solution of one of the exercises gives a core dump.
I narrowed it down to the following program:
#!/usr/bin/perl -w
setpwent;
1 while getpwent;
endpwent;
__END__
Running this results in:
Bus error(coredump)
Thinking it might be the library that dumps core, I also wrote an
equivalent C program:
#include pwd.h
int main (int argc, char * argv []) {
struct passwd * dummy;
setpwent ();
while ((dummy = getpwent ()) != (struct passwd *) NULL) {1;}
endpwent ();
}
This runs without any problems.
ldd showed that the C program and /usr/bin/perl used the same versions
of the C library.
This version of Perl was compiled on an older OS than the machine is
running.
$ uname -a
HP-UX wst08-00 B.11.00 C 9000/785 2002424543 32-user license
$
I tried compiling bleadperl on the machine, but that fails on make
depend (complaining about a C preprocessor). Tomorrow, I might have
a better compiler/preprocessor available, but the sysadmin couldn't
make any garantees.
Abigail
I'm not seeing this problem on HP-UX for a more recent Perl.
spe191:Exit 3/house/smpeters 30 cat core.pl
#!/usr/bin/perl -w
setpwent;
1 while getpwent;
endpwent;
__END__
spe191:Exit 3/house/smpeters 31 perl core.pl
spe191:Exit 3/house/smpeters 32 uname -a
HP-UX spe191 B.11.23 U 9000/800 1187371536 unlimited-user license
spe191:Exit 3/house/smpeters 33 perl -v
This is perl, v5.8.0 built for PA-RISC1.1-thread-multi
(with 1 registered patch, see perl -V for more detail)
Copyright 1987-2002, Larry Wall
Binary build 806 provided by ActiveState Corp. http://www.ActiveState.com
Built 21:44:05 May 2 2003
Change #25084 may have implemented a possible fix to this problem. Are
you still able to replicate this with a current bleadperl?
[perl #7460] HP-UX core dump from op/pwent.t
[jhi - Wed Dec 08 09:02:56 2004]: As in the following ticket, http://rt.perl.org/rt3/Ticket/Display.html?id=7460, this core dump seems to have been fixed prior to 5.8.0. I also built a 5.8.6, and this test passed without any failures. Did you also try that with a *HUGE* number of entries in /etc/group? With HUGE I mean a lot, like over 4k entries And try that in threaded and non-threaded I agree. I do not think this ticket can be yet closed. Change #25084 may have implemented a possible fix to this problem. Are you still able to replicate this with a current bleadperl?
[perl #36969] Syntax error crashing perl-5.8.6
[EMAIL PROTECTED] - Sat Aug 20 19:14:14 2005]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.6.
-
[Please enter your report here]
Source w/syntax error causes crash of Perl.
Unfortunately unable to minimize some reproducible case. It occurs in
mod_perl
environment. Prepared reproducibility binary kit (Fedora Core 4
based):
http://www.jankratochvil.net/priv/perl-semicolon-crash-2005082100-
chrooted.tar.gz
Everything contained inside, reproducible by:
chroot /tmp/chrooted/ /usr/sbin/httpd -d
/home/lace/www/engine/etc/httpd -DPERL -X
Tried also perl-5.8.7 (ported myself) and it still crashes. All the
binaries
tried only in their Fedora Core 4 variants.
Source fix to avoid this bug:
--- home/lace/www/www.jankratochvil.net/project/captive/CVS.pm-orig
2005-08-21 11:00:52.058785000 +0900
+++ home/lace/www/www.jankratochvil.net/project/captive/CVS.pm2005-
08-21 11:01:02.607094776 +0900
@@ -99,7 +99,7 @@
.'hr /requirement: '
.a_href('http://linux-
ntfs.sourceforge.net/downloads.html#downloads','ntfsprogs')
.' '.$format.' ge; 1.8.0'
- .'/td/tr/table';
+ .'/td/tr/table'
.'/td/tr/table';
};
Extracted relevant part from gdb(1):
#0 Perl_pad_free (my_perl=0x8390f10, po=29) at pad.c:1171
1171 SvPADTMP_off(PL_curpad[po]);
(gdb) bt
#0 Perl_pad_free (my_perl=0x8390f10, po=29) at pad.c:1171
#1 0x00e1fafa in Perl_op_clear (my_perl=0x8390f10, o=0x8878480) at
op.c:516
#2 0x00e1fe49 in Perl_op_free (my_perl=0x8390f10, o=0x8878480) at
op.c:380
#3 0x00e1fe04 in Perl_op_free (my_perl=0x8390f10, o=0x88784a8) at
op.c:368
#4 0x00e1fe04 in Perl_op_free (my_perl=0x8390f10, o=0x88a7ac8) at
op.c:368
#5 0x00e1fe04 in Perl_op_free (my_perl=0x8390f10, o=0x88a7b10) at
op.c:368
#6 0x00e1fe04 in Perl_op_free (my_perl=0x8390f10, o=0x88a7aa0) at
op.c:368
#7 0x00e2daff in Perl_newATTRSUB (my_perl=0x8390f10, floor=293,
o=0x88a74a0, proto=0x0, attrs=0x0, block=0x88a7aa0)
at op.c:4376
#8 0x00e1d536 in Perl_yyparse (my_perl=0x8390f10) at perly.y:355
#9 0x00e95628 in S_doeval (my_perl=0x8390f10, gimme=0, startop=0x0,
outside=0x0, seq=137958892) at pp_ctl.c:2847
#10 0x00e9c277 in Perl_pp_require (my_perl=0x8390f10) at pp_ctl.c:3344
#11 0x003e5026 in modperl_perl_global_request_restore () from
/home/lace/www/engine/etc/httpd/modules/mod_perl.so
#12 0x00e436e1 in Perl_runops_debug (my_perl=0x8390f10) at dump.c:1449
#13 0x00df0b9e in S_call_body (my_perl=0x8390f10, myop=0x19,
is_eval=58) at perl.c:2299
#14 0x00df3c73 in Perl_eval_sv (my_perl=0x8390f10, sv=0x83a37a0,
flags=2) at perl.c:2363
#15 0x003db8f8 in modperl_require_module () from
/home/lace/www/engine/etc/httpd/modules/mod_perl.so
#16 0x003d6d0d in modperl_cmd_modules () from
/home/lace/www/engine/etc/httpd/modules/mod_perl.so
#17 0x00d52e02 in ap_add_named_module () from /usr/sbin/httpd
#18 0x00d532f9 in ap_walk_config () from /usr/sbin/httpd
#19 0x00d53839 in ap_process_config_tree () from /usr/sbin/httpd
#20 0x00d5766b in main () from /usr/sbin/httpd
(gdb) p my_perl-Tcurpad[po]
$1 = (SV *) 0x19
(gdb) up
#1 0x00e1fafa in Perl_op_clear (my_perl=0x8390f10, o=0x8878480) at
op.c:516
516 pad_free(o-op_targ);
(gdb) p *o
$2 = {op_next = 0x8878460, op_sibling = 0x8878460, op_ppaddr =
0xe5a962 Perl_pp_concat, op_targ = 29, op_type = 66,
op_seq = 0, op_flags = 70 'F', op_private = 2 '\002'}
(gdb) p *o-op_next
$3 = {op_next = 0x88784a8, op_sibling = 0x0, op_ppaddr = 0xe5a3c0
Perl_pp_const, op_targ = 0, op_type = 5, op_seq = 0,
op_flags = 2 '\002', op_private = 0 '\0'}
You mentioned that this problem occured while using mod_perl. What
version of mod_perl? Also, what version of Apache? Also, do you have
anything smaller that a 22MB file that demonstrates this problem?
[perl #36733] %SIG not properly local-ized
[EMAIL PROTECTED] - Sun Jul 31 23:23:50 2005]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.6.
-
The construct
local %SIG = %SIG;
does *not* make an exact local copy of %SIG, as it should.
The program
perl -e 'print scalar keys %SIG,\n; local %SIG = %SIG; print scalar
keys %SIG, \n'
prints
49
0
instead of (something like)
49
49
as it should.
For comparison, another magic hash, %ENV, does not have the same
problem.
perl -e 'print scalar keys %ENV,\n; local %ENV = %ENV; print scalar
keys %ENV, \n'
61
61
I added Devel::Peek to see more of what's going on. I'm guessing the
copy during localization is not working correctly in this case. The
following chunk of code from mg.c may hold the key to the problem.
if ((mg-mg_flags MGf_COPY) vtbl-svt_copy) {
/* XXX calling the copy method is probably not correct. DAPM */
(void)CALL_FPTR(vtbl-svt_copy)(aTHX_ sv, mg, nsv,
mg-mg_ptr, mg-mg_len);
}
[EMAIL PROTECTED]:~/perl-current$ perl -MDevel::Peek -le'print scalar keys
%SIG; print Dump \%SIG; local %SIG = %SIG; print scalar keys %SIG; print
Dump \%SIG'
69
SV = RV(0x81751a8) at 0x814dc28
REFCNT = 1
FLAGS = (TEMP,ROK)
RV = 0x817ea98
SV = PVHV(0x8152130) at 0x817ea98
REFCNT = 2
FLAGS = (RMG,SHAREKEYS)
IV = 69
NV = 0
MAGIC = 0x8185820
MG_VIRTUAL = PL_vtbl_sig
MG_TYPE = PERL_MAGIC_sig(S)
ARRAY = 0x8187a50 (0:75, 1:42, 2:7, 3:3, 4:1)
hash quality = 93.5%
KEYS = 69
FILL = 53
MAX = 127
RITER = -1
EITER = 0x0
Elt NUM63 HASH = 0xcfaba382
SV = PVMG(0x81635f0) at 0x817ed8c
REFCNT = 1
FLAGS = (GMG,SMG,RMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x81879c0
MG_VIRTUAL = PL_vtbl_sigelem
MG_TYPE = PERL_MAGIC_sigelem(s)
MG_LEN = 5
MG_PTR = 0x81879e0 NUM63
Elt TRAP HASH = 0xdc841002
SV = PVMG(0x8162eb0) at 0x817ead4
REFCNT = 1
FLAGS = (GMG,SMG,RMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x8185930
MG_VIRTUAL = PL_vtbl_sigelem
MG_TYPE = PERL_MAGIC_sigelem(s)
MG_LEN = 4
MG_PTR = 0x8185950 TRAP
Elt NUM42 HASH = 0x2ea7df85
SV = PVMG(0x8163350) at 0x817ec90
REFCNT = 1
FLAGS = (GMG,SMG,RMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x81821b8
MG_VIRTUAL = PL_vtbl_sigelem
MG_TYPE = PERL_MAGIC_sigelem(s)
MG_LEN = 5
MG_PTR = 0x81838f0 NUM42
0
SV = RV(0x81751a8) at 0x814dc28
REFCNT = 1
FLAGS = (TEMP,ROK)
RV = 0x818be1c
SV = PVHV(0x8152190) at 0x818be1c
REFCNT = 2
FLAGS = (RMG,SHAREKEYS)
IV = 0
NV = 0
MAGIC = 0x8185820
MG_VIRTUAL = PL_vtbl_sig
MG_TYPE = PERL_MAGIC_sig(S)
ARRAY = 0x0
KEYS = 0
FILL = 0
MAX = 7
RITER = -1
EITER = 0x0
Re: mentoring new perl 5 porters
On Thu, Sep 01, 2005 at 10:40:18AM +0100, Nicholas Clark wrote: One of the good ideas of the Google Summer of Code was to insist that every project has a mentor; an experienced person to advise and guide the grantee. I'm wondering whether we could embrace this idea for perl5-porters. We often feel rather thin on the ground, and there are many people who might start to help, but the general feeling I get is that most find the first step daunting. Coupled with this I'm currently sitting at YAPC::EU, where there are lots of lightning talk slots free tomorrow. So I was wondering whether I should do a lightning talk about some of the approachable pure-perl tasks in the perltoto, in the hope of gaining some interest. But it would be more likely to succeed in its aim if there are actually some people who would volunteer to consider the task. I wasn't going to name anyone in a talk. People don't actually have to mentor anything - there's no shame in saying you'd consider it and then realising that you can't do it (and no need to say why) You don't need to know C. Let alone the perl source. Just have some confidence about how to go about tasks, and create well formed patches. Does this seem like a good idea? Nicholas Clark One pure-Perl todo that's been discussed, although not in perltodo exactly, was the writing of TODO tests for perlbugs. No special knowledge is needed other than navigating through RT and creating patches for the various test files. Steve Peters [EMAIL PROTECTED]
Re: [perl #37029] Perl bug - help
On Tue, Aug 30, 2005 at 02:29:36PM -0600, Yeoman, Dave wrote: Peter, What we have noticed is; perl v5.8.0 $FindBin::Bin is returning /usr/local/bin and perl v5.8.5 $FindBin::Bin is returning /usr/local/bin/ The next / at the end of bin. OK, this is problem has been previously resolved. The problem is caused by a patch to the Fedora/RedHat Perl package. See previously resolved ticket #30507. A patch to solve the problem has been accepted for future Perls, but has not been released yet. The patch is available at: http://public.activestate.com/cgi-bin/perlbrowse?patch=24753 An updated Perl with this patch may also be available from RedHat/Fedora. Steve Peters [EMAIL PROTECTED]
[perl #37036] perl segfault at 'compile'-time
[EMAIL PROTECTED] - Wed Aug 31 01:38:30 2005]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.7.
-
Hi, i've found a small code that triggers a segfault on the
following perl versions :
5.8.4 (ubuntu package)
5.8.7 (debian testing package)
5.8.7 (freebsd port 5.3-RELEASE)
5.9.1 (compiled on my linux debian testing i386, gcc-4.0.1)
unaffected versions :
version 5.005_03 built for sun4-solaris
Priority is low, since this code is incorrect, but it might help
resolving other issues.
the segfault does not appear when not using 'strict'.
note that no code is executed since it's in a sub that is never
called at runtime.
-- CODE BEGINS HERE --
#!/usr/bin/perl
use strict;
sub s { open $X, my $Y, r; }
-- CODE ENDS HERE --
This appears to have been fixed in bleadperl. I'm not sure, though,
what the exact fix was. Using perl-current, I get:
./perl -Mstrict -wle'sub s { open $X, my $Y, r; }'
Global symbol $X requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.
In the 5.8 releases, the coredump occurs in Perl_ck_open.
#0 0x0809964c in Perl_ck_open ()
(gdb) bt
#0 0x0809964c in Perl_ck_open ()
#1 0x08092698 in Perl_convert ()
#2 0x08089336 in Perl_yyparse ()
#3 0x0806731a in Perl_my_failure_exit ()
#4 0x08068d0e in perl_parse ()
#5 0x0805fda9 in main ()
[perl #37036] perl segfault at 'compile'-time
[EMAIL PROTECTED] - Wed Aug 31 06:01:12 2005]:
Summary: already fixed by patch 24523.
On 2005–08–31, at 10:38, [EMAIL PROTECTED] (via RT) wrote:
-- CODE BEGINS HERE --
#!/usr/bin/perl
use strict;
sub s { open $X, my $Y, r; }
-- CODE ENDS HERE --
[crashes on 5.8.x, 5.9.1]
FWIW, I see the crash (on Darwin) with 5.8.1-7 (omitting 5.8.2, which
I don't have lying around) and 5.9.2, but not with [EMAIL PROTECTED]
Stack trace for the crashed perls is like
Thread 0 Crashed:
0 perl 0x0002893c Perl_ck_open + 452 (op.c:5835)
1 perl 0x00017624 Perl_convert + 452 (op.c:2131)
2 perl 0x001adc60 Perl_yyparse + 8252 (perly.y:427)
3 perl 0x00033018 S_parse_body + 6184 (perl.c:1733)
4 perl 0x000315a4 perl_parse + 1780 (perl.c:1203)
5 perl 0x28b8 main + 308 (perlmain.c:97)
6 perl 0x1fe0 _start + 344 (crt.c:272)
7 perl 0x1e84 start + 60
(That happens to be 5.9.2; others are similar.)
A sniff of the blame log shows that patch 24523 did a little consting
in that area. Reverting the changed lines in bleadperl brings the
crash back. So consting fixed a bug that hadn't even been reported!
Does consting stuff like this get rolled into the various maints as a
matter of course?
This seems to go a bit deeper. My current bleadperl works fine on
OpenBSD, but segfaults on Linux. I'll have to play with the
configurations to see what the backtrace from Linux will show me now.
Re: [perl #37029] Perl bug - help
On Tue, Aug 30, 2005 at 06:51:22AM -0700, Yeoman, Dave wrote: # New Ticket Created by Yeoman, Dave # Please include the string: [perl #37029] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37029 I'm by no means an expert with perl, but I need some Perl help. We have one x440 server with RH 3.0.5 and perl v5.8.0 built for i386-linux-thread-multiand and another server x445 upgraded with RH 4.0 perl v5.8.5 built for i386-linux-thread-multi. The server with Perl v5.8.5 produces different results from the pop (line 458 below) and I'm not sure why. Can you help answer my question? If Cpop() is returning different results, then the array it is pop'ping off of is likely getting populated in a different order, or with different results. From what you've included, though, its hard to say. How are the results different in 5.8.5 from 5.8.0? Steve Peters [EMAIL PROTECTED]
[perl #7728] chdir() dumps core
[RT_System - Sat Sep 22 09:11:39 2001]: Blair Michael G Schwern wrote: On Sat, Sep 22, 2001 at 03:53:53PM -0700, Blair Zajac wrote: Running .\perl -MCwd -wle chdir(); causes a core dump. On 5.6.1?? Using 5.6.1 and 5.8.6 (with up to date Cwd's) on Windows XP, I've been unable to duplicate this bug. My guess is that an old bug in Cwd may have caused the problems.
[perl #7615] (if|unless) ( local ... ) not undone
[EMAIL PROTECTED] - Mon Sep 03 10:43:30 2001]:
-
Local variables declared in a conditional expression of a
conditional block are not restored at the end of scope.
$a = 10;
if (local $a = 1){
}
print $a; # Should be 10, not 1
Applies to local variables declared in 'if (expr)', 'unless(expr)',
and 'elsif (expr)'. Lexical variables are okay, as are local
variables in the conditional expression of a loop block.
This behavior has been fixed in bleadperl by not allowing it.
./perl rt_7615.pl
Can't localize lexical variable $a at rt_7615.pl line 4.
[perl #7615] (if|unless) ( local ... ) not undone
[EMAIL PROTECTED] - Fri Aug 26 09:47:17 2005]:
Steve Peters wrote
This behavior has been fixed in bleadperl by not allowing it.
./perl rt_7615.pl
Can't localize lexical variable $a at rt_7615.pl line 4.
No it hasn't.I suspect you did the wrong test - what's that
lexical doing in the error message?
When I try
perl5.8.6 -w
$a = 10;
if (local $a = 1){
}
print $a; # Should be 10, not 1
__END__
Found = in conditional, should be == at - line 2.
1
the bug is still present.
I presume this is another manifestation of the fact that a conditional
involves *two* scopes, one including the condition and one not.
Perl conflates them, with unfortunate results.
I presume the resaon for conflating them is efficiency.
Sorry, a Cmy crept into my code I was using for testing. So, it
appears at least lexical globals are fixed in blead, although
non-lexicals are still as broken as before. Ticket re-opened.
Re: [Fwd: CPAN Upload: J/JP/JPEACOCK/version-0.47.tar.gz]
On Wed, Aug 24, 2005 at 06:20:11PM +0200, Rafael Garcia-Suarez wrote: John Peacock wrote: The uploaded file version-0.47.tar.gz has entered CPAN as file: $CPAN/authors/id/J/JP/JPEACOCK/version-0.47.tar.gz size: 30615 bytes md5: 9de482a423cae72b9232e8ade250f8dd = Attached, please find a patch to bleadperl to bring it up to snuff. This includes some improvements to the parser to deal with real-world data provided by Andreas Koenig as well as a new validation routine to prevent SEGV's with badly written subclasses (also noted by Andreas). There are also a few changes to make the code more consistent with the rest of the util.c codebase (whitespace as well as Perl_* function naming conventions). Thanks, applied as change #25325. The patch, however, has broken the smokes. cc -L/usr/local/lib -o miniperl \ miniperlmain.o opmini.o libperl.a -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libperl.a(util.o): In function `Perl_vnumify': util.c:(.text+0x56e6): undefined reference to `sv_setpvf' util.c:(.text+0x574f): undefined reference to `sv_catpvf' util.c:(.text+0x57a2): undefined reference to `sv_setpvf' util.c:(.text+0x5805): undefined reference to `sv_catpvf' util.c:(.text+0x58b5): undefined reference to `sv_catpvf' libperl.a(util.o): In function `Perl_vnormal': util.c:(.text+0x5ab5): undefined reference to `sv_setpvf' util.c:(.text+0x5b1b): undefined reference to `sv_catpvf' util.c:(.text+0x5b88): undefined reference to `sv_setpvf' util.c:(.text+0x5bd0): undefined reference to `sv_catpvf' util.c:(.text+0x5c5c): undefined reference to `sv_catpvf' collect2: ld returned 1 exit status make: *** [miniperl] Error 1 Steve Peters [EMAIL PROTECTED]
[PATCH] POD nit in perlvar.pod
And who says spending time on #perl is a waste of time. Following nit found while investigating some particularly nasty code. Steve Peters [EMAIL PROTECTED] --- pod/perlvar.pod.old Sun Aug 7 05:39:09 2005 +++ pod/perlvar.pod Tue Aug 23 14:48:03 2005 @@ -544,7 +544,7 @@ =item C$2 is the same as Csubstr($var, $-[2], $+[2] - $-[2]) -=item C$3 is the same as Csubstr $var, $-[3], $+[3] - $-[3]) +=item C$3 is the same as Csubstr($var, $-[3], $+[3] - $-[3]) =back
[perl #36888] Error message says filehandle but should say dirhandle
[EMAIL PROTECTED] - Fri Aug 12 18:18:40 2005]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.34 running under perl v5.8.0.
-
[Please enter your report here]
plover% perl -wle '$x=pq; print readdir $x'
Bad symbol for filehandle at -e line 1.
But it should be
Bad symbol for dirhandle at -e line 1.
A heuristic. What does Klortho say about that...
#11953 Of course, this is a heuristic, which is a fancy way of saying
that it doesn't work.
This error message above comes from the following code in gv.c
GV *
Perl_gv_IOadd(pTHX_ register GV *gv)
{
if (!gv || SvTYPE((SV*)gv) != SVt_PVGV)
Perl_croak(aTHX_ Bad symbol for filehandle);
if (!GvIOp(gv)) {
#ifdef GV_UNIQUE_CHECK
if (GvUNIQUE(gv)) {
Perl_croak(aTHX_ Bad symbol for filehandle (GV is unique));
}
#endif
GvIOp(gv) = newIO();
}
return gv;
}
Unfortunately, it assumes all typeglobs are filehandles. That means the
following code works, well prints nothing at least, without warning.
perl -Mstrict -wle 'my $x=pq; *X = $x; print readdir X'
It also means that, since there doesn't seem to be a way to distinguish
between filehandles and dirhandles, the following also runs without
warnings.
perl -Mstrict -wle 'open X, foo; print readdir X'
[perl #36967] Pod/Perldoc.pm bug with -m switch
[bepi - Sat Aug 20 15:45:51 2005]: This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.35 running under perl v5.8.7. Pod/Perldoc.pm adds also .pod extension (to perldoc argument) only if: 1) -m switch hasn't been specified or 2) for 'pod/' or 'pods/' subdirectories (even if -m switch has been specified). Sincerely, I don't know if there's a directive and/or specification and/or a reason that suggests to put *.pod files (shipped in a distribution) into a pod/ or pods/ subdirectory, but there are many CPAN modules that don't do it! :-) So for example: % perldoc -m perlboot works well (in general with all core pods, since them lives under pods/ directory), but: % perldoc -m lwpcook doesn't work (with the last you must have LWP installed in your system). IMHO, 1) and 2) conditions are a nonsense together. I've included a simple patch over Pod/Perldoc.pm 3.14 for checking also .pod (indipendently from -m switch presence). Regards - Enrico I'm not sure that this is a problem. Looking at perldoc -h, -m Display module's file in its entirety A POD file, is not, however, a module. So, when I try perldoc -m lwpcook it fails since no lwpcook.pm file exists. When I try perldoc -m lwpcook.pm, the file is found right away and displayed.
[PATCH] Fix a couple of random warnings
Attached is a patch for a couple of random warnings I've looked at but
haven't gotten to fixing. The fix in nostdio.h is complained about
by gcc if compiling with -Wundef. The change in perl.c is complained about
by bcc without -DDEBUGGING. It looks like bcc dislike code like if(0){.
Enjoy!
Steve Peters
[EMAIL PROTECTED]
--- nostdio.h.old 2003-04-16 16:25:36.0 -0500
+++ nostdio.h 2005-08-09 06:09:00.0 -0500
@@ -111,7 +111,7 @@
#define _flsbuf(c,f) _CANNOT _flsbuf_
#define fdopen(fd,p) _CANNOT _fdopen_
#define fileno(f) _CANNOT _fileno_
-#if SFIO_VERSION 2101L
+#if defined(SFIO_VERSION) SFIO_VERSION 2101L
#define flockfile(f) _CANNOT _flockfile_
#define ftrylockfile(f) _CANNOT _ftrylockfile_
#define funlockfile(f) _CANNOT _funlockfile_
--- perl.c.old 2005-07-20 07:58:35.0 -0500
+++ perl.c 2005-08-09 06:20:32.0 -0500
@@ -2238,8 +2238,10 @@
if (!PL_restartop) {
DEBUG_x(dump_all());
+#ifdef DEBUGGING
if (!DEBUG_q_TEST)
PERL_DEBUG(PerlIO_printf(Perl_debug_log, \nEXECUTING...\n\n));
+#endif
DEBUG_S(PerlIO_printf(Perl_debug_log, main thread is 0x%UVxf\n,
PTR2UV(thr)));
[perl #24342] Coredump when shortening an array during use
[chip - Wed Oct 29 13:54:58 2003]: According to [EMAIL PROTECTED]: It seems a list will return an alias to the last element. It further seems the element is not REFCOUNT++ed (same as with @_) and that this alias is retrieved before the right hand side of the expression is evaluated. Bobdammit! Not another stack refcount bug! Sorry about that. It's just fricking irritating that the stack still doesn't refcount its contents. Well, recent changes have caught the coredump. Now, bleadperl is just panicking instead. ./perl -wle '[EMAIL PROTECTED],[EMAIL PROTECTED]' Name main::a used only once: possible typo at -e line 1. panic: sv_upgrade to unknown type 255 at -e line 1.
Re: Smoke [5.9.3] 25248 FAIL(F) openbsd 3.7 (i386/1 cpu)
On Mon, Aug 01, 2005 at 10:41:00AM -0500, [EMAIL PROTECTED] wrote: Automated smoke report for 5.9.3 patch 25248 mccoy.peters.homeunix.org: Intel Pentium III (GenuineIntel 686-class, 512KB L2 cache) (548 MHz) (i386/1 cpu) onopenbsd - 3.7 using cc version 3.3.5 (propolice) smoketime 8 hours 36 minutes (average 1 hour 4 minutes) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25248 Configuration (common) none --- - F F F F F F F F -Duse64bitint F F F F -Duseithreads F F F F -Duseithreads -Duse64bitint | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] [stdio/perlio] -DDEBUGGING [stdio/perlio] -Duse64bitint [stdio/perlio] -DDEBUGGING -Duse64bitint [stdio/perlio] -Duseithreads [stdio/perlio] -DDEBUGGING -Duseithreads [stdio/perlio] -Duseithreads -Duse64bitint [stdio/perlio] -DDEBUGGING -Duseithreads -Duse64bitint ../t/op/sprintf.t...FAILED 147 It appears that the additional sprintf.t test is causing failures on OpenBSD. ok 142 ok 143 ok 144 ok 145 ok 146 not ok 147 %.0g -0.0 -0 0 # No minus ok 148 ok 149 ok 150 ok 151 Steve Peters [EMAIL PROTECTED]
Re: [PATCH] perlfunc.pod grammar fixes
On Thu, Jul 28, 2005 at 08:55:17AM +0200, Piotr Fusik wrote: I have doubts about the following changes: Note that the $year element is Inot simply the last two digits of -the year. If you assume it is, then you create non-Y2K-compliant +the year. If you assume it is and then you create non-Y2K-compliant programs--and you wouldn't want to do that, would you? and removed. Note that a block by itself is semantically identical to a loop -that executes once. Thus Clast can be used to effect an early +that executes once. Thus Clast can be used to affect an early exit out of such a block. effect is a noun, while affect is a verb. This is a common English grammar screw-up. Sets the current position for the Creaddir routine on DIRHANDLE. POS -must be a value returned by Ctelldir. Has the same caveats about -possible directory compaction as the corresponding system library +must be a value returned by Ctelldir. Cseekdir also Has the same caveats +about possible directory compaction as the corresponding system library routine. Has changed to has. -You can effect a sleep of 250 milliseconds this way: +You can affect a sleep of 250 milliseconds this way: Again, effect vs. affect. Here, this is a verb, so affect is the right word. the original quicksort was faster. 5.8 has a sort pragma for limited control of the sort. Its rather blunt control of the -underlying algorithm may not persist into future perls, but the +underlying algorithm may not persist into future Perls, but the ability to characterize the input or output in implementation independent ways quite probably will. See Lsort. Removed. Attached below is the updated patch. Steve Peters [EMAIL PROTECTED] --- pod/perlfunc.pod.old2005-07-27 11:57:23.0 -0500 +++ pod/perlfunc.pod2005-07-28 05:32:01.0 -0500 @@ -25,7 +25,7 @@ of scalar arguments or list values; the list values will be included in the list as if each individual element were interpolated at that point in the list, forming a longer single-dimensional list value. -Elements of the LIST should be separated by commas. +Commas should separate elements of the LIST. Any function in the list below may be used either with or without parentheses around its arguments. (The syntax descriptions omit the @@ -139,7 +139,7 @@ Creadlink, Crename, Crmdir, Cstat, Csymlink, Csysopen, Cumask, Cunlink, Cutime -=item Keywords related to the control flow of your perl program +=item Keywords related to the control flow of your Perl program Ccaller, Ccontinue, Cdie, Cdo, Cdump, Ceval, Cexit, Cgoto, Clast, Cnext, Credo, Creturn, Csub, Cwantarray @@ -337,7 +337,7 @@ The C-T and C-B switches work as follows. The first block or so of the file is examined for odd characters such as strange control codes or characters with the high bit set. If too many strange characters (30%) -are found, it's a C-B file, otherwise it's a C-T file. Also, any file +are found, it's a C-B file; otherwise it's a C-T file. Also, any file containing null in the first block is considered a binary file. If C-T or C-B is used on a filehandle, the current IO buffer is examined rather than the first block. Both C-T and C-B return true on a null @@ -351,7 +351,7 @@ a system call. (This doesn't work with C-t, and you need to remember that lstat() and C-l will leave values in the stat structure for the symbolic link, not the real file.) (Also, if the stat buffer was filled by -a Clstat call, C-T and C-B will reset it with the results of Cstat _). +an Clstat call, C-T and C-B will reset it with the results of Cstat _). Example: print Can do.\n if -r $a || -w _ || -x _; @@ -368,7 +368,7 @@ As of Perl 5.9.1, as a form of purely syntactic sugar, you can stack file test operators, in a way that C-f -w -x $file is equivalent to -C-x $file -w _ -f _. (This is only syntax fancy : if you use +C-x $file -w _ -f _. (This is only syntax fancy: if you use the return value of C-f $file as an argument to another filetest operator, no special magic will happen.) @@ -394,7 +394,7 @@ =item alarm Arranges to have a SIGALRM delivered to this process after the -specified number of wallclock seconds have elapsed. If SECONDS is not +specified number of wallclock seconds has elapsed. If SECONDS is not specified, the value stored in C$_ is used. (On some machines, unfortunately, the elapsed time may be up to one second less or more than you specified because of how seconds are counted, and process @@ -547,13 +547,13 @@ in the CLASSNAME package. If CLASSNAME is omitted, the current package is used. Because a Cbless is often the last thing in a constructor, it returns the reference for convenience. Always use the two-argument -version if the function doing the blessing might be inherited by a -derived class. See Lperltoot and Lperlobj for more about the blessing -(and blessings) of objects. +version if a derived class might inherit
Re: [PATCH] perlfunc.pod grammar fixes
On Thu, Jul 28, 2005 at 05:32:56AM -0500, Steve Peters wrote: On Thu, Jul 28, 2005 at 08:55:17AM +0200, Piotr Fusik wrote: I have doubts about the following changes: Clearly, I need to read my mailbox completely after waking up in the morning :-/ Steve Peters [EMAIL PROTECTED]
[perl #36665] delete $ENV{FOO} leaves $FOO visible in subprocesses on Cygwin Perl
[EMAIL PROTECTED] - Wed Jul 27 00:47:52 2005]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.7.
-
[Please enter your report here]
For at least Perl 5.8.7 on Cygwin, delete()ing an environment variable
does not apparently remove that variable from the environment of a
subprocess. Here is a short repro case:
#!/usr/bin/perl
use strict;
use warnings;
$ENV{SHOULD_NEVER_BE_SEEN} = hello world;
delete($ENV{SHOULD_NEVER_BE_SEEN});
system(printenv | grep SHOULD_NEVER_BE_SEEN);
On Unix systems this script appropriately prints nothing.
On an up to date Cygwin installation this prints hello world.
This bug manifested itself as a problem with Test::Harness on Cygwin
Perl. For context, see the e-mail thread around this summary message:
http://cygwin.com/ml/cygwin/2005-07/msg01201.html
[Please do not change anything below this line]
-
---
Flags:
category=core
severity=medium
---
Site configuration information for perl v5.8.7:
Configured by gerrit at Fri Jul 8 20:35:50 2005.
Summary of my perl5 (revision 5 version 8 subversion 7) configuration:
Platform:
osname=cygwin, osvers=1.5.18(0.13242), archname=cygwin-thread-
multi-64int
uname='cygwin_nt-5.1 inspiron 1.5.18(0.13242) 2005-07-02 20:30
i686 unknown unknown cygwin '
config_args='-de -Dmksymlinks -Duse64bitint -Dusethreads
-Doptimize=-O3 -Dman3ext=3pm -Dusesitecustomize'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=y, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing
-pipe -I/usr/local/include',
optimize='-O3',
cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe
-I/usr/local/include'
ccversion='', gccversion='3.4.4 (cygming special) (gdc 0.12,
using dmd 0.125)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8,
byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define,
longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='ld2', ldflags =' -s -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib /lib
libs=-lgdbm -ldb -lcrypt -lgdbm_compat
perllibs=-lcrypt -lgdbm_compat
libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
cccdlflags=' ', lddlflags=' -s -L/usr/local/lib'
Locally applied patches:
---
@INC for perl v5.8.7:
/usr/lib/perl5/5.8/cygwin
/usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/cygwin
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8
/usr/lib/perl5/vendor_perl/5.8
.
---
Environment for perl v5.8.7:
HOME=/cygdrive/c/Documents and Settings/andrew/home
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/cygdrive/c/Documents and
Settings/andrew/home/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/system32
PERL_BADLANG (unset)
SHELL (unset)
[perl #36665] delete $ENV{FOO} leaves $FOO visible in subprocesses on Cygwin Perl
[stmpeters - Wed Jul 27 07:16:02 2005]:
[EMAIL PROTECTED] - Wed Jul 27 00:47:52 2005]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.7.
-
[Please enter your report here]
For at least Perl 5.8.7 on Cygwin, delete()ing an environment
variable
does not apparently remove that variable from the environment of a
subprocess. Here is a short repro case:
#!/usr/bin/perl
use strict;
use warnings;
$ENV{SHOULD_NEVER_BE_SEEN} = hello world;
delete($ENV{SHOULD_NEVER_BE_SEEN});
system(printenv | grep SHOULD_NEVER_BE_SEEN);
On Unix systems this script appropriately prints nothing.
On an up to date Cygwin installation this prints hello world.
This bug manifested itself as a problem with Test::Harness on Cygwin
Perl. For context, see the e-mail thread around this summary
message:
http://cygwin.com/ml/cygwin/2005-07/msg01201.html
Oops, sorry about the empty reply. I had a problem similar to this with
locally scoped environment variables, but could only get it to occur on
Cygwin with Windows NT (see RT #30952). Upon some examination, it
appears that the two problems are the same. The attempted workaround in
RT #30952 does undef the environment variable as far as Perl is
concerned, but it does seem to leave it empty in the environment.
[PATCH] Squish warnings in POSIX.xs
POSIX.xs has recently been giving the following warnings:
POSIX.xs: In function `XS_POSIX_sigaction':
POSIX.xs:1348: warning: comparison of distinct pointer types lacks a cast
POSIX.xs:1357: warning: assignment from incompatible pointer type
The problem comes with assigning Perl's Sigaction_t to sigaction.sa_handler. It
seems to like Cvoid *, so that's what we can give it. It's paassing its
tests from what I can see, but we'll see how the smokes do on platforms other
than Linux and OpenBSD.
Steve Peters
[EMAIL PROTECTED]
--- ext/POSIX/POSIX.xs.old Tue Jul 19 16:46:37 2005
+++ ext/POSIX/POSIX.xs Wed Jul 27 10:50:17 2005
@@ -1347,7 +1347,7 @@
/* Get back whether the old handler used safe signals. */
svp = hv_fetch(oldaction, SAFE, 4, TRUE);
- sv_setiv(*svp, oact.sa_handler == PL_csighandlerp);
+ sv_setiv(*svp, oact.sa_handler == (void*)PL_csighandlerp);
}
if (action) {
@@ -1356,7 +1356,8 @@
(BTW, csighandler is very different from sighandler.) */
svp = hv_fetch(action, SAFE, 4, FALSE);
act.sa_handler = (*svp SvTRUE(*svp))
-? PL_csighandlerp : PL_sighandlerp;
+? (void*)PL_csighandlerp :
+ (void*)PL_sighandlerp;
/* Vector new Perl handler through %SIG.
(The core signal handlers read %SIG to dispatch.) */
Re: [PATCH] Squish warnings in POSIX.xs
On Wed, Jul 27, 2005 at 05:06:24PM +0100, Robin Barker wrote: -Original Message- From: Nicholas Clark [mailto:[EMAIL PROTECTED] Sent: 27 July 2005 17:03 To: Steve Peters Cc: perl5-porters@perl.org Subject: Re: [PATCH] Squish warnings in POSIX.xs On Wed, Jul 27, 2005 at 11:01:00AM -0500, Steve Peters wrote: POSIX.xs has recently been giving the following warnings: POSIX.xs: In function `XS_POSIX_sigaction': POSIX.xs:1348: warning: comparison of distinct pointer types lacks a cast POSIX.xs:1357: warning: assignment from incompatible pointer type The problem comes with assigning Perl's Sigaction_t to sigaction.sa_handler. It seems to like Cvoid *, so that's what we can give it. It's paassing its tests from what I can see, but we'll see how the smokes do on platforms other than Linux and OpenBSD. Casting pointers to functions to pointers to data isn't conformant ANSI C. - These casts can be laundered via a (sufficiently) long unsigned integer. Use FPTR2DPTR and DPTR2FPTR defined in perl.h Hateful GNU! OK, I'll re-work and try again :-/ Steve
[PATCH] perlfunc.pod grammar fixes
This patch has it all: passive voice removals; spelling fixes; which vs. that change; e.g. fixes; and etc. Thanks to Pod::Simple::RTF and and handy grammar checker, this was all made much easier. Enjoy! Steve Peters [EMAIL PROTECTED] --- pod/perlfunc.pod.old2005-07-27 11:57:23.0 -0500 +++ pod/perlfunc.pod2005-07-27 21:55:46.0 -0500 @@ -25,7 +25,7 @@ of scalar arguments or list values; the list values will be included in the list as if each individual element were interpolated at that point in the list, forming a longer single-dimensional list value. -Elements of the LIST should be separated by commas. +Commas should separate elements of the LIST. Any function in the list below may be used either with or without parentheses around its arguments. (The syntax descriptions omit the @@ -139,7 +139,7 @@ Creadlink, Crename, Crmdir, Cstat, Csymlink, Csysopen, Cumask, Cunlink, Cutime -=item Keywords related to the control flow of your perl program +=item Keywords related to the control flow of your Perl program Ccaller, Ccontinue, Cdie, Cdo, Cdump, Ceval, Cexit, Cgoto, Clast, Cnext, Credo, Creturn, Csub, Cwantarray @@ -337,7 +337,7 @@ The C-T and C-B switches work as follows. The first block or so of the file is examined for odd characters such as strange control codes or characters with the high bit set. If too many strange characters (30%) -are found, it's a C-B file, otherwise it's a C-T file. Also, any file +are found, it's a C-B file; otherwise it's a C-T file. Also, any file containing null in the first block is considered a binary file. If C-T or C-B is used on a filehandle, the current IO buffer is examined rather than the first block. Both C-T and C-B return true on a null @@ -351,7 +351,7 @@ a system call. (This doesn't work with C-t, and you need to remember that lstat() and C-l will leave values in the stat structure for the symbolic link, not the real file.) (Also, if the stat buffer was filled by -a Clstat call, C-T and C-B will reset it with the results of Cstat _). +an Clstat call, C-T and C-B will reset it with the results of Cstat _). Example: print Can do.\n if -r $a || -w _ || -x _; @@ -368,7 +368,7 @@ As of Perl 5.9.1, as a form of purely syntactic sugar, you can stack file test operators, in a way that C-f -w -x $file is equivalent to -C-x $file -w _ -f _. (This is only syntax fancy : if you use +C-x $file -w _ -f _. (This is only syntax fancy: if you use the return value of C-f $file as an argument to another filetest operator, no special magic will happen.) @@ -394,7 +394,7 @@ =item alarm Arranges to have a SIGALRM delivered to this process after the -specified number of wallclock seconds have elapsed. If SECONDS is not +specified number of wallclock seconds has elapsed. If SECONDS is not specified, the value stored in C$_ is used. (On some machines, unfortunately, the elapsed time may be up to one second less or more than you specified because of how seconds are counted, and process @@ -547,13 +547,13 @@ in the CLASSNAME package. If CLASSNAME is omitted, the current package is used. Because a Cbless is often the last thing in a constructor, it returns the reference for convenience. Always use the two-argument -version if the function doing the blessing might be inherited by a -derived class. See Lperltoot and Lperlobj for more about the blessing -(and blessings) of objects. +version if a derived class might inherit the function doing the blessing. +See Lperltoot and Lperlobj for more about the blessing (and blessings) +of objects. Consider always blessing objects in CLASSNAMEs that are mixed case. Namespaces with all lowercase names are considered reserved for -Perl pragmata. Builtin types have all uppercase names, so to prevent +Perl pragmata. Builtin types have all uppercase names. To prevent confusion, you may wish to avoid such package names as well. Make sure that CLASSNAME is a true value. @@ -844,8 +844,8 @@ =item continue BLOCK -Actually a flow control statement rather than a function. If there is a -Ccontinue BLOCK attached to a BLOCK (typically in a Cwhile or +Ccontinue is actually a flow control statement rather than a function. If +there is a Ccontinue BLOCK attached to a BLOCK (typically in a Cwhile or Cforeach), it is always executed just before the conditional is about to be evaluated again, just like the third part of a Cfor loop in C. Thus it can be used to increment a loop variable, even when the loop has been @@ -887,7 +887,7 @@ Creates a digest string exactly like the crypt(3) function in the C library (assuming that you actually have a version there that has not -been extirpated as a potential munition). +been extirpated as a potential munitions). crypt() is a one-way hash function. The PLAINTEXT and SALT is turned into a short string, called a digest, which is returned. The same @@ -902,13 +902,13 @@ primarily used to check if two
[PATCH] id est is i.e.
Sorry, but this is a pet peeve. The proper abbreviation for
id est is i.e., not ie. or ie. ARRRAGAGAFASD!
Sorry, I feel better now. Attached is a patch to fix the included
pod files.
Steve Peters
[EMAIL PROTECTED]
--- pod/perlfunc.pod.old2005-07-26 20:21:51.0 -0500
+++ pod/perlfunc.pod2005-07-26 20:22:25.0 -0500
@@ -1181,7 +1181,7 @@
If LIST is empty and C$@ contains an object reference that has a
CPROPAGATE method, that method will be called with additional file
and line number parameters. The return value replaces the value in
-C$@. ie. as if C $@ = eval { [EMAIL PROTECTED]PROPAGATE(__FILE__,
__LINE__) };
+C$@. i.e. as if C $@ = eval { [EMAIL PROTECTED]PROPAGATE(__FILE__,
__LINE__) };
were called.
If C$@ is empty then the string CDied is used.
@@ -2995,7 +2995,7 @@
reading.
Since v5.8.0, perl has built using PerlIO by default. Unless you've
-changed this (ie Configure -Uuseperlio), you can open file handles to
+changed this (i.e. Configure -Uuseperlio), you can open file handles to
in memory files held in Perl scalars via:
open($fh, '', \$variable) || ..
--- pod/perlguts.pod.old2005-07-26 20:22:54.0 -0500
+++ pod/perlguts.pod2005-07-26 20:23:39.0 -0500
@@ -2171,7 +2171,7 @@
=item p
-This function has a CPerl_ prefix; ie, it is defined as CPerl_av_fetch
+This function has a CPerl_ prefix; i.e. it is defined as CPerl_av_fetch
=item d
--- pod/perlhack.pod.old2005-07-26 20:24:21.0 -0500
+++ pod/perlhack.pod2005-07-26 20:25:03.0 -0500
@@ -877,9 +877,9 @@
=item Exception handing
-Perl's exception handing (ie Cdie etc) is built on top of the low-level
+Perl's exception handing (i.e. Cdie etc) is built on top of the low-level
Csetjmp()/Clongjmp() C-library functions. These basically provide a
-way to capture the current PC and SP registers and later restore them; ie
+way to capture the current PC and SP registers and later restore them; i.e.
a Clongjmp() continues at the point in code where a previous Csetjmp()
was done, with anything further up on the C stack being lost. This is why
code should always save values using CSAVE_FOO rather than in auto
--- pod/perlintern.pod.old 2005-07-26 20:25:20.0 -0500
+++ pod/perlintern.pod 2005-07-26 20:26:03.0 -0500
@@ -28,7 +28,7 @@
circumstances we should decrement the refcount of the parent when freeing
the child.
-There is a further complication with non-closure anonymous subs (ie those
+There is a further complication with non-closure anonymous subs (i.e. those
that do not refer to any lexicals outside that sub). In this case, the
anonymous prototype is shared rather than being cloned. This has the
consequence that the parent may be freed while there are still active
@@ -268,7 +268,7 @@
=item SAVECLEARSV
-Clear the pointed to pad value on scope exit. (ie the runtime action of 'my')
+Clear the pointed to pad value on scope exit. (i.e. the runtime action of 'my')
voidSAVECLEARSV (SV **svp)
[perl #969] shifting of bitvecs considered broken
Resubmitting a bug report of mine back from February; this time through the proper channel (perlbug, not p5p). [paste] While editing my Damn Book I re-remembered that couple of months back I ran into an anomaly in the handling of bitvectors. Fiction: you have a bitvector which you want to shift. The current (5.005_03-MT5) fact: perl -wle '$b = ; vec($b, 0, 1) = 1;print unpack(b*, $b);$b=1;print unpack(b*, $b)' 1000 1100 Huh? Adding -w tells more, as usual: Argument ^A isn't numeric in left_shift at -e line 1. So left_shift assumes that the argument to shift is a number, but ^A isn't, so it gets converted to string zero 0 (48, 0x30, 0b110). I consider this behaviour to be rather broken. I think $b = 1 should shift the whole bitvector left by one position and vec($b, 2, 8) = 2 should shift the bits 16..23 right by two positions (of course not leaking into bits 8..15). Just so we're clear, and to add a proper TODO test case, what would you consider the proper output to be?
[PATCH] Convert t/op/vec.t to test.pl
The attached patch converts t/op/vec.t to use test.pl for handling its
test cases rather than doing everything through Cprint statements.
Steve Peters
[EMAIL PROTECTED]
--- t/op/vec.t.old Sat Feb 15 01:37:09 2003
+++ t/op/vec.t Wed Jul 20 08:02:56 2005
@@ -1,91 +1,90 @@
#!./perl
-print 1..31\n;
+BEGIN {
+chdir 't' if -d 't';
+@INC = qw(. ../lib);
+}
+require test.pl;
+plan( tests = 31 );
+
my $Is_EBCDIC = (ord('A') == 193) ? 1 : 0;
-print vec($foo,0,1) == 0 ? ok 1\n : not ok 1\n;
-print length($foo) == 0 ? ok 2\n : not ok 2\n;
+is(vec($foo,0,1), 0);
+is(length($foo), 0);
vec($foo,0,1) = 1;
-print length($foo) == 1 ? ok 3\n : not ok 3\n;
-print unpack('C',$foo) == 1 ? ok 4\n : not ok 4\n;
-print vec($foo,0,1) == 1 ? ok 5\n : not ok 5\n;
+is(length($foo), 1);
+is(unpack('C',$foo), 1);
+is(vec($foo,0,1), 1);
-print vec($foo,20,1) == 0 ? ok 6\n : not ok 6\n;
+is(vec($foo,20,1), 0);
vec($foo,20,1) = 1;
-print vec($foo,20,1) == 1 ? ok 7\n : not ok 7\n;
-print length($foo) == 3 ? ok 8\n : not ok 8\n;
-print vec($foo,1,8) == 0 ? ok 9\n : not ok 9\n;
+is(vec($foo,20,1), 1);
+is(length($foo), 3);
+is(vec($foo,1,8), 0);
vec($foo,1,8) = 0xf1;
-print vec($foo,1,8) == 0xf1 ? ok 10\n : not ok 10\n;
-print ((unpack('C',substr($foo,1,1)) 255) == 0xf1 ? ok 11\n : not ok
11\n);
-print vec($foo,2,4) == 1 ? ok 12\n : not ok 12\n;
-print vec($foo,3,4) == 15 ? ok 13\n : not ok 13\n;
+is(vec($foo,1,8), 0xf1);
+is((unpack('C',substr($foo,1,1)) 255), 0xf1);
+is(vec($foo,2,4), 1);;
+is(vec($foo,3,4), 15);
vec($Vec, 0, 32) = 0xbaddacab;
-print $Vec eq \xba\xdd\xac\xab ? ok 14\n : not ok 14\n;
-print vec($Vec, 0, 32) == 3135089835 ? ok 15\n : not ok 15\n;
+is($Vec, \xba\xdd\xac\xab);
+is(vec($Vec, 0, 32), 3135089835);
# ensure vec() handles numericalness correctly
$foo = $bar = $baz = 0;
vec($foo = 0,0,1) = 1;
vec($bar = 0,1,1) = 1;
$baz = $foo | $bar;
-print $foo eq 1 $foo == 1 ? ok 16\n : not ok 16\n;
-print $bar eq 2 $bar == 2 ? ok 17\n : not ok 17\n;
-print $foo $bar $baz eq 1 2 3 ? ok 18\n : not ok 18\n;
+ok($foo eq 1 $foo == 1);
+ok($bar eq 2 $bar == 2);
+ok($foo $bar $baz eq 1 2 3);
# error cases
$x = eval { vec $foo, 0, 3 };
-print not if defined $x or $@ !~ /^Illegal number of bits in vec/;
-print ok 19\n;
+like($@, /^Illegal number of bits in vec/);
+$@ = undef;
$x = eval { vec $foo, 0, 0 };
-print not if defined $x or $@ !~ /^Illegal number of bits in vec/;
-print ok 20\n;
+like($@, /^Illegal number of bits in vec/);
+$@ = undef;
$x = eval { vec $foo, 0, -13 };
-print not if defined $x or $@ !~ /^Illegal number of bits in vec/;
-print ok 21\n;
+like($@, /^Illegal number of bits in vec/);
+$@ = undef;
$x = eval { vec($foo, -1, 4) = 2 };
-print not if defined $x or $@ !~ /^Negative offset to vec in lvalue
context/;
-print ok 22\n;
-print not if vec('abcd', 7, 8);
-print ok 23\n;
+like($@, /^Illegal number of bits in vec/);
+$@ = undef;
+ok(! vec('abcd', 7, 8));
# UTF8
# N.B. currently curiously coded to circumvent bugs elswhere in UTF8 handling
$foo = \x{100} . \xff\xfe;
$x = substr $foo, 1;
-print not if vec($x, 0, 8) != 255;
-print ok 24\n;
+is(vec($x, 0, 8), 255);
+$@ = undef;
eval { vec($foo, 1, 8) };
-print not if $@;
-print ok 25\n;
+ok(! $@);
+$@ = undef;
eval { vec($foo, 1, 8) = 13 };
-print not if $@;
-print ok 26\n;
+ok(! $@);
if ($Is_EBCDIC) {
-print not if $foo ne \x8c\x0d\xff\x8a\x69;
-print ok 27\n;
+is($foo, \x8c\x0d\xff\x8a\x69);
}
else {
-print not if $foo ne \xc4\x0d\xc3\xbf\xc3\xbe;
-print ok 27\n;
+is($foo, \xc4\x0d\xc3\xbf\xc3\xbe);
}
$foo = \x{100} . \xff\xfe;
$x = substr $foo, 1;
vec($x, 2, 4) = 7;
-print not if $x ne \xff\xf7;
-print ok 28\n;
+is($x, \xff\xf7);
# mixed magic
$foo = \x61\x62\x63\x64\x65\x66;
-print not if vec(substr($foo, 2, 2), 0, 16) != 25444;
-print ok 29\n;
+is(vec(substr($foo, 2, 2), 0, 16), 25444);
vec(substr($foo, 1,3), 5, 4) = 3;
-print not if $foo ne \x61\x62\x63\x34\x65\x66;
-print ok 30\n;
+is($foo, \x61\x62\x63\x34\x65\x66);
# A variation of [perl #20933]
{
@@ -94,6 +93,5 @@
vec($s, 1, 1) = 1;
my @r;
$r[$_] = \ vec $s, $_, 1 for (0, 1);
-print not if (${ $r[0] } != 0 || ${ $r[1] } != 1);
-print ok 31\n;
+ok(!(${ $r[0] } != 0 || ${ $r[1] } != 1));
}
Re: [PATCH] support POSIX SA_SIGINFO
On Wed, Jul 20, 2005 at 02:40:54PM +0300, Jarkko Hietaniemi wrote:
My (?:m(?:is)?)?adventures in the world of POSIX signals continue.
Now to followup on my own patch of two years ago [1], here is support
for SA_SIGINFO (see man sigaction), which allows additional information
to be passed on to the signal handlers (beyond the signal number).
I am not entirely proud of the argument passing scheme to the signal
handler (the name of the signal, a hash ref with the POSIX/SUSv3 fields
unpacked, and the binary blob of the whole siginfo struct) but I tried
to find a solution somewhere between being a POSIX purist and a portable
pragmatist.
Unfortunately, it looks like this patch causes some compile failures on
BSD-related systems, including Cygwin. The failure occue in mg.c with the
following error...
mg.c: In function `Perl_sighandler':
mg.c:2720: error: union has no member named `_file'
*** Error code 1
Below is the code in question.
2698 #if defined(HAS_SIGACTION) defined(SA_SIGINFO)
2699 {
2700 struct sigaction oact;
2701
2702 if (sigaction(sig, 0, oact) == 0 oact.sa_flags
SA_SIGINFO) {
2703 siginfo_t *sip;
2704 va_list args;
2705
2706 va_start(args, sig);
2707 sip = (siginfo_t*)va_arg(args, siginfo_t*);
2708 if (sip) {
2709HV *sih = newHV();
2710SV *rv = newRV_noinc((SV*)sih);
2711/* The siginfo fields signo, code, errno, pid, uid,
2712 * addr, status, and band are defined by
POSIX/SUSv3. */
2713hv_store(sih, signo, 5, newSViv(sip-si_signo),
0);
2714hv_store(sih, code,4, newSViv(sip-si_code),
0);
2715hv_store(sih, errno, 5, newSViv(sip-si_errno),
0);
2716hv_store(sih, uid, 3, newSViv(sip-si_uid),
0);
2717hv_store(sih, pid, 3, newSViv(sip-si_pid),
0);
2718hv_store(sih, addr,4,
newSVuv(PTR2UV(sip-si_addr)), 0);
2719hv_store(sih, status, 6, newSViv(sip-si_status),
0);
2720hv_store(sih, band,4, newSViv(sip-si_band),
0);
2721EXTEND(SP, 2);
2722PUSHs((SV*)rv);
2723PUSHs(newSVpv((void*)sip, sizeof(*sip)));
2724 }
2725 }
2726 }
2727 #endif
Steve Peters
[EMAIL PROTECTED]
[perl #18905] Using HTTP::Daemon with Perl 5.8.0 cuts off web pages on Win32
[m0zart - Thu Dec 05 11:42:26 2002]: This is a bug report for perl from [EMAIL PROTECTED] generated with the help of perlbug 1.34 running under perl v5.8.0. - [Please enter your report here] I have used Perl 5.00503 and Perl 5.6.1 in combination with the HTTP::daemon to run a single-connection webserver for a few years now, and have never had a problem. Recently however, after building Perl 5.8.0 for Win32, I ran into a severe problem. After a web page is sent across, it gets truncated/cut-off by the time it reaches the Browser. This happens for any browser, whether it be Netscape or IE on Windows, or Netscape on UNIX. I downloaded the Perl 5.8.0 binary distribution, to see if perhaps there was a build problem on my machine in particular, but the exact same problem occurs. I thought this might be related to Ticket #16234, but setting the environment variable PERLIO to :raw doesn't fix the problem. The pages are actually losing A LOT of the webpages, between 2/3 and 3/4. I am sending this to core rather than libraries because the bug seems to be deeper in Perl's IO layer, rather than a part of the HTTP/Daemon.pm module. NOTE: I also built Perl 5.8.0 for several UNIX platforms (Solaris, DecAlpha, HPUX, AIX, Linux for x86, Linux for s390, Reliant/Sinix, and Sequent/Dynix) and didn't have this problem on any of those. Without code to demonstrate this problem, it is difficult to say whether the problem is in the module or in the core. Do you have any code to demonstrate this problem?
[PATCH] Final (hopefully) fix for fchdir
I noticed the blead's were still failing for HP-UX and AIX and ran a
few tests on HP testdrive systems to see what was happening. There is
a syntax error in code that did not previously compile. Below is the
patch that will compile on HP-UX.
Enjoy,
Steve Peters
[EMAIL PROTECTED]
--- pp_sys.c.old2005-07-18 12:03:27.0 -0500
+++ pp_sys.c2005-07-18 22:55:54.0 -0500
@@ -3592,7 +3592,7 @@
#ifdef HAS_DIRFD
PUSHi(fchdir(dirfd(IoDIRP(io))) = 0);
#else
- DIE(aTHX PL_no_func, dirfd);
+ DIE(aTHX_ PL_no_func, dirfd);
#endif
}
else {
Re: fchmod, fchown, fchdir
On Thu, Jul 14, 2005 at 03:27:04PM -0700, Gisle Aas wrote: I would like to be able to pass file handles to chmod(), chown() and chdir() and have perl call the corresponding fxxx() function. This is similar to how perl treats the argument of stat() or truncate(). Below is an implementation that make perl call fchmod(). If there are no objections to this approach, I'll complete a patch that includes the other 2 functions and comes with tests and documentation. Configure already probes for the availability of these functions. If I remember correctly, these are all in perltodo, so, I would guess that doing it would be just fine. :) Steve Peters [EMAIL PROTECTED]
[perl #34450] Coding defect in Perl_newFOROP causing Access Violation
[EMAIL PROTECTED] - Wed Mar 16 06:02:13 2005]: If scalar(sv) is null (not sure why it would be off hand), and expr is not a list type, append will just return the expr object, which is not of type OP_LIST. Perl_convert will then return a new LISTOP. The crash is because the code casts a LISTOP to a LOOP which is bigger as Copy takes the expected type as an argument, and assumes the data size from that rather than the actual size of the data. -Original Message- From: Rafael Garcia-Suarez via RT [mailto:[EMAIL PROTECTED] Sent: 16 March 2005 12:02 To: Sargent, John Subject: Re: [perl #34450] Coding defect in Perl_newFOROP causing Access Violation Sargent, John wrote: In op.c, line 3856 (ish) the cast to a LOOP* is incorrect. in that the memory allocated inside Perl_convert when the OP type is NOT OP_LIST is I can't figure out a case where this wouldn't be a list op. Have you code to reproduce this ? Let me clarify. Do you have any Perl and/or XS code that demonstrates this problem?
[perl #33003] Core dump on simple instruction
[shay - Wed Dec 15 03:19:13 2004]: Michael G Schwern wrote: It appears to no longer be coring on 5.8.6. It is still crashing for me on Win32 :( Produces an Access Violation error (more or less the Win32 equivalent of coring). Here's the call stack at the crash (using 5.8.6): Perl_av_extend(av * 0x01830f5c, long 2147483647) line 165 + 15 bytes Perl_av_store(av * 0x01830f5c, long 2147483647, sv * 0x28175070 _PL_sv_undef) line 322 + 13 bytes Perl_av_fill(av * 0x01830f5c, long 2147483647) line 783 + 18 bytes Perl_magic_setarylen(sv * 0x01830f80, magic * 0x01835648) line 1670 + 68 bytes Perl_mg_set(sv * 0x01830f80) line 237 + 14 bytes Perl_pp_right_shift() line 1667 + 46 bytes Perl_runops_debug() line 1449 + 9 bytes S_run_body(long 1) line 1937 perl_run(interpreter * 0x00233e90) line 1853 + 9 bytes RunPerl(int 2, char * * 0x00232430, char * * 0x00232c68) line 217 + 12 bytes main(int 2, char * * 0x00232430, char * * 0x00232c68) line 18 + 18 bytes PERL! mainCRTStartup + 227 bytes KERNEL32! 77e814c7() At this point, the debugger shows newmax is 2147483647 and tmp is 2147482080. It crashes with bleadperl too. - Steve Perl_av_extend() has a lot of different paths depending on several #define's. Can you please look up to see what you have for the following #defines? PERL_MALLOC_WRAP STRANGE_MALLOC MYMALLOC Thanks!
[perl #9565] [PATCH] /op/groups.t bug
[stmpeters - Tue Jul 05 13:19:42 2005]:
[EMAIL PROTECTED] - Fri Mar 07 11:03:22 2003]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.34 running under perl v5.8.0.
-
[Please enter your report here]
The regression test fails with:
t/op/grepok
t/op/groups..FAILED at test 1
t/op/gv..ok
Here is more detailed output from t/op/groups:
# ./perl op/groups.t
# groups = uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),2015(releases),1(bin)
#
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),2015(releases),1(bin)
# g0 = 0(root) 1(bin) 2(daemon) 3(sys) 4(adm) 6(disk) 10(wheel)
2015(releases) 1(bin)
# g1 = root bin daemon sys adm disk wheel releases bin
1..2
# pwgid = 0, pwgnam = root
# gr = bin releases wheel disk adm sys daemon bin
#gr1 is adm bin bin daemon disk releases sys wheel
#gr2 is adm bin daemon disk releases sys wheel
not ok 1
ok 2
I think the problem may be due to a duplicate entry in our NIS
/etc/group map. We have two groups with ID 1, but with different
names. One of the names is bin.
I was able to reproduce this bug, although, only while root. Anyways,
the test does make poor assumptions about the correctness of the data
in
/etc/group. Patch forthcoming.
The problem here is that users can have duplicate group numbers or names
in /etc/group. The attached patch will uniquely sort the group names
for comparisons.
--- t/op/groups.t.old 2005-01-21 09:52:53.0 -0600
+++ t/op/groups.t 2005-07-13 08:26:49.0 -0500
@@ -137,7 +137,9 @@
# Or anybody else who can have spaces in group names.
$gr1 = join(' ', grep(!$did{$_}++, sort split(' ', join(' ',
@gr;
} else {
- $gr1 = join(' ', sort @gr);
+# Don't assume that there aren't duplicate groups
+my %seen;
+ $gr1 = join(' ', sort grep defined $_ !$seen{$_}++, @gr);
}
[perl #9012] Segfault with -DXst
[EMAIL PROTECTED] - Wed Apr 24 06:40:12 2002]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.33 running under perl v5.6.1.
-
[Please enter your report here]
This program displays a severe memory leak:
$x = 0123456789;
for (1..10) {
my @s;
$x =~ /.*(.+?)(?{push @s, $1})(?!)/;
}
END { print STDERR Global destruction\n }
(Probably related to the bug report I just filed.)
While investigating it, I ran:
/src/bleadperl-build/perl -DXst /tmp/mem.pl
Perl died from a segmentation fault partway through the run. However,
/src/bleadperl-build/perl -DX /tmp/mem.pl
runs and completes normally.
I have attached the run output below.
plover% /src/bleadperl-build/perl -DXst /tmp/mem.pl
Pad 0x816dcb0 alloc 1 for range
Pad 0x816dcb0 sv 1
Pad 0x816dcb0 alloc 2 for range
Pad 0x816dcb0 sv 2
Pad 0x816dcb0 alloc 3 for padsv
Pad 0x8175040 alloc 1 for padsv
Pad 0x8175040 alloc 2 for push
Pad 0x816dcb0 free 1
Pad 0x816dcb0 free 2
Pad 0x8175240 alloc 1 for stringify
=
(/tmp/mem.pl:8) null
=
(/tmp/mem.pl:8) const(PV(Global destruction\12\0))
= PV(Global destruction\12\0)
(/tmp/mem.pl:8) stringify
Pad 0x8175240 sv 1
Pad 0x8175240 sv 1
Pad 0x8175240 swipe 1
Pad 0x8175240 free 1
EXECUTING...
=
(/tmp/mem.pl:0) enter
=
(/tmp/mem.pl:0) nextstate
=
(/tmp/mem.pl:2) const(PV(0123456789\0))
= PV(0123456789\0)
(/tmp/mem.pl:2) gvsv(main::x)
= PV(0123456789\0) UNDEF
(/tmp/mem.pl:2) sassign
= PV(0123456789\0)
(/tmp/mem.pl:2) nextstate
=
(/tmp/mem.pl:3) pushmark
= *
(/tmp/mem.pl:3) const(IV(1))
= * IV(1)
(/tmp/mem.pl:3) const(IV(10))
= * IV(1) IV(10)
(/tmp/mem.pl:3) gv(main::_)
= * IV(1) IV(10) GV()
(/tmp/mem.pl:3) enteriter
=
(/tmp/mem.pl:3) iter
= SV_YES
(/tmp/mem.pl:3) and
=
(/tmp/mem.pl:3) nextstate
= SV_YES PVNV(10)
(/tmp/mem.pl:4) padav(@s)
Pad 0x816dcb0 sv 3
= SV_YES PVNV(10) IV(0)
(/tmp/mem.pl:4) nextstate
= SV_YES PVNV(10)
(/tmp/mem.pl:5) gvsv(main::x)
= SV_YES PVNV(10) PV(0123456789\0)
(/tmp/mem.pl:5) match
= SV_YES PVNV(10)
(/tmp/mem.pl:5) nextstate
= SV_YES PVNV(10)
((re_eval 1):1) pushmark
= SV_YES PVNV(10) *
((re_eval 1):1) padavSegmentation fault (core dumped)
plover%
This core dump is still around in [EMAIL PROTECTED] Below is the backtrace.
#0 0x0810dee7 in Perl_debop (my_perl=0x82d5008, o=0x830ab38) at dump.c:1639
1639sv = *av_fetch(comppad, o-op_targ, FALSE);
(gdb) bt
#0 0x0810dee7 in Perl_debop (my_perl=0x82d5008, o=0x830ab38) at dump.c:1639
#1 0x0810d788 in Perl_runops_debug (my_perl=0x82d5008) at dump.c:1597
#2 0x081ff73d in S_regmatch (my_perl=0x82d5008, prog=0x82f5390)
at regexec.c:3219
#3 0x08205c50 in S_regmatch (my_perl=0x82d5008, prog=0x82f537c)
at regexec.c:4078
#4 0x0820684c in S_regmatch (my_perl=0x82d5008, prog=0x82f5374)
at regexec.c:4145
#5 0x081f8dde in S_regtry (my_perl=0x82d5008, prog=0x82f5330,
startpos=0x82ecd08 0123456789) at regexec.c:2225
#6 0x081f61a4 in Perl_regexec_flags (my_perl=0x82d5008, prog=0x82f5330,
stringarg=0x82ecd08 0123456789, strend=0x82ecd12 ,
strbeg=0x82ecd08 0123456789, minend=0, sv=0x82f2488, data=0x0,
flags=3)
at regexec.c:1765
#7 0x0813d317 in Perl_pp_match (my_perl=0x82d5008) at pp_hot.c:1280
#8 0x0810d7ed in Perl_runops_debug (my_perl=0x82d5008) at dump.c:1600
#9 0x0806aaf6 in S_run_body (my_perl=0x82d5008, oldscope=1) at perl.c:1918
#10 0x0806a1c0 in perl_run (my_perl=0x82d5008) at perl.c:1847
#11 0x0806074b in main (argc=3, argv=0xbfe47764, env=0xbfe47774)
at perlmain.c:103
[perl #9336] Changing a for array dumps core
[RT_System - Tue May 14 00:25:37 2002]: [EMAIL PROTECTED] wrote: Ok, i know the docs say not to do things like this, but it still shouldn't dump core: perl -wle '$#F-- [EMAIL PROTECTED]' You play too much golf, don't you. This bug is confirmed with bleadperl. Strangely, moving the assignment out of the for() statement : $ bleadperl -e '@x=1..5; $#x-- for @x' doesn't dump core. This coredump seems to have been resolved sometime prior to Perl 5.8.7. perl -wle '$#F-- [EMAIL PROTECTED]' Use of freed value in iteration at -e line 1.
[perl #15063] /tmp issues
[nicholas - Sat Feb 28 09:50:01 2004]: On Sat, Feb 28, 2004 at 05:39:33PM +, Dave Mitchell wrote: On Sat, Feb 28, 2004 at 05:06:51PM +, Nicholas Clark wrote: Change 22258 by [EMAIL PROTECTED] on 2004/02/01 17:40:02 This touches quite a few dual life modules maintained outside the core, yet it doesn't seem to tweak any version numbers. I presume that this changes are not yet passed on upstream? [I was about to merge it to maint then had second thoughts because of this] I applied this patch when I was still in a state of blissful ignorance about dual-life modules. Since then I have matured into a state of fearful ignorance. I belive these days one is supposed to bump up the sub-version number and notify the maintainers. Would you like me to do this? I think the combination is what Rafael said should be done. Certainly the changes need to get to the upstream authors. Given that I'm trying to get a maint snapshot out this weekend, I'd be happy not to be the person doing it :-) So if you could, that'd be great. Nicholas Clark Change 22409 by [EMAIL PROTECTED] on 2004/02/28 23:29:10 Bump version numbers of moules affected by change #22258 (removing /tmp and other insecurities) Done.
[perl #8584] Fatal warning
[RT_System - Mon Feb 18 14:05:01 2002]: On Tue, Feb 19, 2002 at 07:57:02AM +0200, Jarkko Hietaniemi wrote: Death! Death! Death! Sorry, got carried away in there for a moment. kosh:/tmp/jhi/perl ; ./perl -lne 'print if /[..]/' POSIX syntax [. .] belongs inside character classes in regex; marked by -- HERE in m/[..] -- HERE / at -e line 1. POSIX syntax [. .] is reserved for future extensions in regex; marked by -- HERE in m/[..] -- HERE / kosh:/tmp/jhi/perl ; In case there was confusion: #14765 did that. Great, this appears to be resolved. perl -lne 'print if /[..]/' ; echo $? POSIX syntax [. .] is reserved for future extensions in regex; marked by -- HERE in m/[..] -- HERE / at -e line 1. 255
Re: [perl #17487] ncftp only handles http
On Tue, Jul 12, 2005 at 12:00:02PM +0200, Rafael Garcia-Suarez wrote: On 7/12/05, Michael G Schwern via RT [EMAIL PROTECTED] wrote: You mention that you have wget. CPAN.pm triest wget last after trying ncftp*. As its the most capable of all the options available it should be tried first. Then lynx. Then finally ncftp*. A patch for this is attached. Can you include curl in it ? At the beginning or something ? It's extremely capable and has excellent error reporting. Since curl is included by default on Mac OS X and wget and lynx is not, I'd like to see curl a little farther up the list as well. Steve Peters [EMAIL PROTECTED]
[perl #15995] regexp test failures on win32 with VC++ 5.0
[wjones - Thu Jun 19 10:30:36 2003]: This patch works for me. Index: regcomp.c === RCS file: /usr0/sweng/src/active/CVS.repo/perl/regcomp.c,v retrieving revision 1.1.1.4 retrieving revision 1.4 diff -u -r1.1.1.4 -r1.4 --- regcomp.c 29 Jul 2002 16:20:00 - 1.1.1.4 +++ regcomp.c 19 Jun 2003 17:10:39 - 1.4 @@ -19,6 +19,17 @@ * with the POSIX routines of the same names. */ +/* + * Turn off all optimization with MS Visual C under Windows. + * Optimization makes tests 495 and 496 fail in op/regexp.t. + * This is a fix for Perl bug #15995 (really a bug in MSC). + * _MSC_VER == 1100 indicates MS Visual C 5.0. Other versions + * of the compiler may or may not have the same bug. +*/ +#if defined(WIN32) defined(_MSC_VER) _MSC_VER == 1100 +#pragma optimize( , off ) +#endif + #ifdef PERL_EXT_RE_BUILD /* need to replace pregcomp et al, so enable that */ # ifndef PERL_IN_XSUB_RE Can anyone confirm whether these failures still occur on Windows with VC++ 5.0 and if this patch fixes the problem?
[perl #20353] Perl 5.8.0 fails make test on Cobalt Raq4 in Math::BigInt
[EMAIL PROTECTED] - Thu Jan 16 06:33:13 2003]: The standard melody for building Perl 5.8.0 fails at make test on Cobalt Raq4: My input: rm -f config.sh Policy.sh sh Configure -de make make test It fails here: lib/Math/BigInt/t/bare_mbf...ok lib/Math/BigInt/t/bare_mbi...ok lib/Math/BigInt/t/bare_mif...FAILED at test 511 lib/Math/BigInt/t/bigfltpm...make[2]: *** [_test_tty] Error 139 make[2]: Leaving directory `/home/software/perl-5.8.0' make[1]: *** [_test] Error 2 make[1]: Leaving directory `/home/software/perl-5.8.0' make: *** [test] Error 2 repeating make test gives the same result. [EMAIL PROTECTED]:perl-5.8.0 ./myconfig Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.2.14c11, archname=i586-linux uname='linux tasc.surrogacy.org 2.2.14c11 #2 wed jun 28 00:55:51 pdt 2000 i586 unknown ' config_args='-de' 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 ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O3', cppflags='-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='2.95.2 19991024 (release)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.1.3' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='- rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' (make test for Perl 5.6.1, built in the same way, on the same machine, reports no problems.) Greetings, Norbert. Tels, Does this problem look familiar to you?
[perl #21999] Unsuccessful regex still alters $1
[EMAIL PROTECTED] - Sat Apr 19 08:32:56 2003]:
I was raised on the belief that an unsuccessful regex match leaves $1
and
friends at their previous values. So I was surprised to discover an
exception to that rule. It's been around for a long time, so perhaps
I'm
missing something. OTOH, if this is not expected behavior, perhaps
there's
a bug.
% cat foo
#!/usr/bin/perl
for (qw(843 foo 23skidoo bar 345)) {
print /^(\d+)$/ ? $_ matched : $_ didn't match;
print ; \$1 = $1\n;
}
% ./foo
843 matched; $1 = 843
foo didn't match; $1 = 843
23skidoo didn't match; $1 = 8
bar didn't match; $1 = 8
345 matched; $1 = 345
In the case of the unsuccessful match against 23skidoo, $1 is
truncated to
the first character of its previous value. This is in 5.6.1, 5.8.0,
and 5.9.0.
Just as a historical point of reference: In 5.004_04, $1 is set to the
first character of 23skidoo, and is undef on an unsuccessful match:
843 matched; $1 = 843
foo didn't match; $1 =
23skidoo didn't match; $1 = 2
bar didn't match; $1 =
345 matched; $1 = 345
From perlre.pod
...failed matches in Perl do not reset the match variables.
so the above is a bug. My guess, and this is just a guess, is that on
the failed match, SvCUR_set() is getting called somewhere. Looking at
the results with Devel::Peek...
843 matched; $1 = 843
SV = PVMG(0x801ae3c0) at 0x8812a6f4
REFCNT = 1
FLAGS = (GMG,SMG,READONLY,pPOK)
IV = 0
NV = 0
PV = 0x85bf0300 843\0
CUR = 3
LEN = 4
MAGIC = 0x7df8efa0
MG_VIRTUAL = PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x8812a6e0
MG_LEN = 1
MG_PTR = 0x7c1a19c0 1
foo didn't match; $1 = 843
SV = PVMG(0x801ae3c0) at 0x8812a6f4
REFCNT = 1
FLAGS = (GMG,SMG,READONLY,pPOK)
IV = 0
NV = 0
PV = 0x85bf0300 843\0
CUR = 3
LEN = 4
MAGIC = 0x7df8efa0
MG_VIRTUAL = PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x8812a6e0
MG_LEN = 1
MG_PTR = 0x7c1a19c0 1
23skidoo didn't match; $1 = 8
SV = PVMG(0x801ae3c0) at 0x8812a6f4
REFCNT = 1
FLAGS = (GMG,SMG,READONLY,pPOK)
IV = 0
NV = 0
PV = 0x85bf0300 8\0
CUR = 1
LEN = 4
MAGIC = 0x7df8efa0
MG_VIRTUAL = PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x8812a6e0
MG_LEN = 1
MG_PTR = 0x7c1a19c0 1
bar didn't match; $1 = 8
SV = PVMG(0x801ae3c0) at 0x8812a6f4
REFCNT = 1
FLAGS = (GMG,SMG,READONLY,pPOK)
IV = 0
NV = 0
PV = 0x85bf0300 8\0
CUR = 1
LEN = 4
MAGIC = 0x7df8efa0
MG_VIRTUAL = PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x8812a6e0
MG_LEN = 1
MG_PTR = 0x7c1a19c0 1
345 matched; $1 = 345
SV = PVMG(0x801ae3c0) at 0x8812a6f4
REFCNT = 1
FLAGS = (GMG,SMG,READONLY,pPOK)
IV = 0
NV = 0
PV = 0x85bf0300 345\0
CUR = 3
LEN = 4
MAGIC = 0x7df8efa0
MG_VIRTUAL = PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x8812a6e0
MG_LEN = 1
MG_PTR = 0x7c1a19c0 1
[perl #22959] missing symbols from embed.h when testing B::Generate
[jimc - Sun Jul 13 22:36:22 2003]: When doing 'make test' on B::Generate on 5.8.1-19893, I get missing symbols, which are defined in embed.h, and used successfully in core. For me at least, theyre not available to this XS module (though other non-CORE XS's build ok). I dunno whether its a bug in CORE, in B::Generate, or a PEBCAK error, but I thought it safest to flag it, in case it impacts 5.8.1. [EMAIL PROTECTED] maintperl]$ grep -r fold_constants * embed.fnc:p |OP*|fold_constants |OP* arg embed.h:#define fold_constants Perl_fold_constants embed.h:#define fold_constants(a) Perl_fold_constants(aTHX_ a) op.c:Perl_fold_constants(pTHX_ register OP *o) op.c:return fold_constants(o); op.c:return fold_constants((OP *) unop); op.c:return fold_constants((OP *)binop); op.c:o = fold_constants(o); op.c: return fold_constants(o); proto.h:PERL_CALLCONV OP* Perl_fold_constants(pTHX_ OP* arg); [EMAIL PROTECTED] B-Generate-1.06-mod]$ make /usr/local/bin/perl5.8.1 ./Build lib/B/Generate.pm - blib/lib/B/Generate.pm cc -c -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno- strict-aliasing - \ I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/ gdbm -g -O2 \ -I/usr/local/lib/perl5/5.8.1/i686-linux-thread-multi/CORE -o lib/B/Generate.o \ lib/B/Generate.c lib/B/Generate.bs - blib/arch/auto/B/Generate/Generate.bs cc -shared -L/usr/local/lib -o blib/arch/auto/B/Generate/Generate.so lib/B/Generate.o [EMAIL PROTECTED] B-Generate-1.06-mod]$ make test /usr/local/bin/perl5.8.1 ./Build test testCan't load 'blib/arch/auto/B/Generate/Generate.so' for module \ B::Generate: blib/arch/auto/B/Generate/Generate.so: undefined symbol: fold_constants at \ /usr/local/lib/perl5/5.8.1/i686-linux-thread-multi/DynaLoader.pm line 229. at test.pl line 4 The issue here is that Cfold_constants is not part of the public API and is supposed to only be available only in the Perl core. A more complete look at embed.h shows #ifdef PERL_CORE #define find_script Perl_find_script #define force_list Perl_force_list #define fold_constants Perl_fold_constants #endif So, given this, I'd say this is a bug in B::Generate, rather than the Perl core.
[perl #23098] core dump - perl in malloc(): error: recursive call
[EMAIL PROTECTED] - Wed Jul 23 08:17:50 2003]: Hello! i want to consult with you about strange behavior of perl v5.6.1 on FreeBSD 5.1 beta. may be something is wrong ... with perl or with me =) i wrote a small mail proxy which listens connections from local network and redirects clients to outside. this proxy forks 2 processes: first for writing queries from local client to outer mail server, second for writing queries from outer mail server to local client. i think it is ordinary. this scheme is simple and it works, but ... but sometimes it all dumps with 'perl.core' and error like this 'perl in malloc(): error: recursive call', but all processes are still alive. there is no any regularity in this dumps. i don't think that this errors are because of me. may be kernel? or may be perl? please help me to solve this problem! ps. the _same_ code in C (POSIX is POSIX =) works great, of course with out any dumps. pss. if you don't want to look into this, please tell me where i can know more about my problem. We're happy to look into core dumps more deeply. Can you please provide some sample code to replicate the problem, or possibly, a backtrace of the coredump?
Re: [perl #2269] unpack(NaN) big baddaboom
On Tue, Jul 12, 2005 at 08:09:07PM -0700, Michael G Schwern via RT wrote: [EMAIL PROTECTED] - Mon Mar 06 02:33:55 2000]: Running following program causes Floating point exception on FreeBSD 3.2-STABLE *and* 4.0-CURRENT #0: Tue Feb 29 02:11:52 AST 2000 (but not on Linux 2.3.44 #12 SMP) (all 5.00503) ===8==8==8==8 #!/usr/bin/perl my $packed = \0\0\xc0\x7f; print STDERR len: , length($packed), bytes: , unpack(H*, $packed), \n; my $float = unpack(f, $packed); print STDERR float done\n; print STDERR float: $float\n; exit 0; ===8==8==8==8 hayek$ ./moo.pl len: 4 bytes: c07f float done Floating point exception hayek$ echo $? 136 hayek$ ===8==8==8==8 Anyone have a FreeBSD machine handy with a recent Perl on it to try this out? Testdrive probably does.
Re: Smoke [5.9.3] 25093 FAIL(F) openbsd 3.7 (macppc/1 cpu)
On Thu, Jul 07, 2005 at 07:56:39PM -0500, Steve Peters wrote:
On Fri, Jul 08, 2005 at 12:33:21AM +0200, Abe Timmerman wrote:
Op een mooie zomerdag (Friday 08 July 2005 01:03),schreef Abe Timmerman:
...
The t/io/*.t failures (on all mij bsd/darwin systems) do not show up if I
run
the smoke script directly, they only show up when the smoke-scripts are run
from a shell-script that loops over them.
Is this a BSD issue or a perl issue?
Beside a few initial bumps with OpenBSD 3.7, I've not had any major issues
with the smokes. In fact, my last failed smoke was about three weeks ago.
Looking at the failures, they involve dup'ing STDIN into another filehandle.
Would it be possible for you to smoke with the following patch to see
what the exact error is? I'm hoping STDERR isn't snuffed out completely in
smoke testing, so hopefully these warnings will give us some answers.
Steve Peters
[EMAIL PROTECTED]
--- t/io/open.t.old Tue Oct 19 12:07:33 2004
+++ t/io/open.t Fri Jul 8 16:33:19 2005
@@ -234,7 +234,7 @@
}
# used to try to open a file [perl #17830]
-ok( open(my $stdin, , fileno STDIN), 'dup fileno(STDIN) into
lexical fh');
+ok( open(my $stdin, , fileno STDIN), 'dup fileno(STDIN) into
lexical fh') || _diag $!;
}
SKIP: {
--- t/io/dup.t.old Sun Sep 14 09:54:11 2003
+++ t/io/dup.t Fri Jul 8 16:34:46 2005
@@ -96,7 +96,7 @@
isnt(fileno(F), fileno(STDOUT));
close F;
-ok(open(F, =STDIN));
+ok(open(F, =STDIN)) || _diag $!;
is(fileno(F), fileno(STDIN));
close F;
Re: Smoke [5.9.3] 25093 FAIL(F) openbsd 3.7 (macppc/1 cpu)
On Fri, Jul 08, 2005 at 12:33:21AM +0200, Abe Timmerman wrote: Op een mooie zomerdag (Friday 08 July 2005 01:03),schreef Abe Timmerman: ... The t/io/*.t failures (on all mij bsd/darwin systems) do not show up if I run the smoke script directly, they only show up when the smoke-scripts are run from a shell-script that loops over them. Is this a BSD issue or a perl issue? Beside a few initial bumps with OpenBSD 3.7, I've not had any major issues with the smokes. In fact, my last failed smoke was about three weeks ago. Steve Peters [EMAIL PROTECTED]
Re: rt.perl.org wedged?
On Wed, Jul 06, 2005 at 10:51:07AM -0700, Michael G Schwern wrote: For about a half hour now web requests to rt.perl.org are hanging. Same here. Pingable. Traceroute-able. Nothing doing on the web though. Steve Peters [EMAIL PROTECTED]
Re: Replies to old bugs
On Wed, Jul 06, 2005 at 10:30:36AM -0700, Yitzchak Scott-Thoennes wrote: On Wed, Jul 06, 2005 at 08:19:25AM -0700, Michael G Schwern wrote: On Tue, Jul 05, 2005 at 09:22:13PM -0700, Robert Spier wrote: What do I have to do special to make my replies to old bugs in rt.perl.org show up on p5p like Steve's do? Put p5p (well, the email address) in the CC line in the web interface. Ahh, of course. Thanks! We don't do this automatically so as to avoid mail loops. Yeah, the mail loop thing again. Can't RT stick some sort of X-From-RT header in the email to indicate that p5p shouldn't forward it back to RT? Yes, wouldn't that work? To make sure we are all working from the same point of view: is there anyone who thinks web replies to perl tickets *shouldn't* go to p5p automatically? I typically copy P5P on the bugs I work on unless they resulted in a change and the committer forgot to resolve the ticket, or they involved asking for for more information which has never been received (I usually think that a couple of years is long enough to wait for a reply). Also, certain administrators have additional powers to deal with spam in the p5p queue, so I'm guessing you didn't want to know what happened to Get Free-Pay-Per-View Movies earlier this morning. Although many of the tickets I work on go through with little or no comment, and despite the occasional lambastings, copying p5p has prevented me from shooting myself in the foot several times. Thankfully, most modern browsers will autocomplete the CC field on a reply, so I rarely have to do more that type a 'p' to get 'perl5-porters@perl.org' filled in when replying to a ticket in RT. That is a very minimal part of the whole process of going through the old tickets, and, if it prevents some nasty mail loops, I'm more than happy to hit the 'p' key. Steve Peters [EMAIL PROTECTED]
Re: Replies to old bugs
On Wed, Jul 06, 2005 at 12:04:52PM -0700, Michael G Schwern wrote: On Wed, Jul 06, 2005 at 01:57:21PM -0500, Steve Peters wrote: Although many of the tickets I work on go through with little or no comment, and despite the occasional lambastings, copying p5p has prevented me from shooting myself in the foot several times. Thankfully, most modern browsers will autocomplete the CC field on a reply, so I rarely have to do more that type a 'p' to get 'perl5-porters@perl.org' filled in when replying to a ticket in RT. That is a very minimal part of the whole process of going through the old tickets, and, if it prevents some nasty mail loops, I'm more than happy to hit the 'p' key. I think the issue isn't so much a matter of keystrokes as it is people having to know the right voodoo to get their web replies forwarded back to p5p and actually be seen, reviewed and acted upon. OK, we all know the right voodoo now. Steve Peters [EMAIL PROTECTED]
Re: Replies to old bugs
On Wed, Jul 06, 2005 at 12:54:00PM -0700, Michael G Schwern wrote: On Wed, Jul 06, 2005 at 03:50:27PM -0400, Ronald J Kimball wrote: Maybe there could be a checkbox, CC perl5-porters on this reply. Is there any non-technical reason why we don't want p5p CC'd? ie. Why make this optional? I don't think that the tickets closed for a lack of information and/or responsiveness need to go to p5p, although the comment stating why it is closed is an important part of the ticket. Steve Peters [EMAIL PROTECTED]
[perl #3451] coredump in map modifying input array
[RT_System - Tue Jul 04 01:44:33 2000]:
On Fri, 30 Jun 2000 17:50:58 +0200, Wolfgang Laun wrote:
I know that modifying the list from a map of foreach is a no-no,
but: The following program crashes with a segmentation fault,
and this is something that should not happen, right?
#! /usr/bin/perl -w
use strict;
my @a = ( 'abc', 'def', 'ghi' );
@a = map { splice( @a, 0 ); $_ } ( @a );
print done: @a\n;
The array that's being iterated over in grep/map/foreach should
probably be marked readonly for the duration of the iteration.
Patch welcome.
Sarathy
[EMAIL PROTECTED]
Cool! The new panic recently added caught this case.
[EMAIL PROTECTED]:~/perl-fix$ ./perl rt_3451.pl
panic: sv_upgrade to unknown type 255 at rt_3451.pl line 2.
Re: [perl #3451] coredump in map modifying input array
On Tue, Jul 05, 2005 at 06:28:49PM +0200, Rafael Garcia-Suarez wrote: On 5 Jul 2005 10:22:53 -, Steve Peters via RT [EMAIL PROTECTED] wrote: Cool! The new panic recently added caught this case. [EMAIL PROTECTED]:~/perl-fix$ ./perl rt_3451.pl panic: sv_upgrade to unknown type 255 at rt_3451.pl line 2. That's not a fix. This bad upgrade really shouldn't happen, and probably indicates access to corrupted memory or something. So the risk of segfault is probably still there. Sorry, I should have been more clear. Its not a fix, but we do have a good idea as to why the segfault did occur. A little more detective work is needed to fix the actual problem.
Re: Debian bug #227621: getgrent out of memory
On Tue, Jul 05, 2005 at 06:46:51PM +0200, Rafael Garcia-Suarez wrote: On 7/5/05, Brendan O'Dea [EMAIL PROTECTED] wrote: Debian byg 227621 (http://bugs.debian.org/227621) reports OOM problems processing /etc/group files with large lines. I can't find this in the change log now, but I note in perl590delta : For threaded Perls certain system database functions like getpwent() and getgrent() now grow their result buffer dynamically, instead of failing. This means that at sites with lots of users and groups the functions no longer fail by returning only partial results. So I'd suggest to try to reproduce with bleadperl; if fixed in blead, find and backport the fix. (should be straightforward :) I find the analysis by Steinar H. Gunderson quite interesting. Please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=227621msg=18 for his full analysis. Steve Peters [EMAIL PROTECTED]
[perl #21502] 5.8.0 regression failure for t/op/groups
[EMAIL PROTECTED] - Fri Mar 07 11:03:22 2003]: This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.34 running under perl v5.8.0. - [Please enter your report here] The regression test fails with: t/op/grepok t/op/groups..FAILED at test 1 t/op/gv..ok Here is more detailed output from t/op/groups: # ./perl op/groups.t # groups = uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),2015(releases),1(bin) # groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),2015(releases),1(bin) # g0 = 0(root) 1(bin) 2(daemon) 3(sys) 4(adm) 6(disk) 10(wheel) 2015(releases) 1(bin) # g1 = root bin daemon sys adm disk wheel releases bin 1..2 # pwgid = 0, pwgnam = root # gr = bin releases wheel disk adm sys daemon bin #gr1 is adm bin bin daemon disk releases sys wheel #gr2 is adm bin daemon disk releases sys wheel not ok 1 ok 2 I think the problem may be due to a duplicate entry in our NIS /etc/group map. We have two groups with ID 1, but with different names. One of the names is bin. I was able to reproduce this bug, although, only while root. Anyways, the test does make poor assumptions about the correctness of the data in /etc/group. Patch forthcoming.
[perl #34035] Segfault involving goto and loops
[EMAIL PROTECTED] - Thu Feb 03 13:24:32 2005]:
On Thu, Feb 03, 2005 at 03:15:35PM -, Benjamin Smith wrote:
Below is a short program which segfaults with 5.8.5 and 5.8.6. On
5.6.1 the second print shows $op as undef, but there is no segfault.
Thanks for the report. The bug is still present in bleedperl, and can be
reduced to the following:
my $ip = 0;
while ($ip 2) {
if ($ip++) {
goto X;
}
next;
X:
} continue { }
The segfaults happens during loop exist because earlier, the goto is
popping two BLOCKs rather than one:
$ ./perl -Dstvl /tmp/p
...
(/tmp/p:6) nextstate
STACK 0: MAIN
CX 0: BLOCK =
CX 1: LOOP =
CX 2: BLOCK =
CX 3: BLOCK =
(/tmp/p:7) goto
Unwinding block 3, type BLOCK
Unwinding block 2, type BLOCK
(/tmp/p:7) TOPBLOCK scope 4 at pp_ctl.c:2551
STACK 0: MAIN
CX 0: BLOCK =
CX 1: LOOP =
(/tmp/p:7) nextstate
However, I havn't got time at the moment to look into this further; got to
design the lighting for a play next week, and my supply of potential
displacement activites far exceeds the meager hours I have left before
the deadline. If another P5Per wants to run with this, be my guest...
Dave.
It looks like this has been fixed in bleadperl, but I'm not sure when.
[EMAIL PROTECTED]:~/sandbox$ ~/perl-current/perl rt_34035.pl
ARRAY(0x8193f68)
ARRAY(0x8193f68)
[PATCH] Skip nit in t/op/lfs.t
There's a skip message in t/op/lfs.t that tries to print out C$^0
(that's a zero) instead of C$^O (that's an o).
Steve Peters
[EMAIL PROTECTED]
--- t/op/lfs.t.old 2002-12-01 21:29:18.0 -0600
+++ t/op/lfs.t 2005-07-04 10:05:24.0 -0500
@@ -67,7 +67,7 @@
# Known haves that have problems running this test
# (for example because they do not support sparse files, like UNICOS)
if ($^O eq 'unicos') {
-print 1..0 # Skip: no sparse files in $^0, unable to test large files\n;
+print 1..0 # Skip: no sparse files in $^O, unable to test large files\n;
bye();
}
[perl #36450] Lvalue sub fails under debugger
[EMAIL PROTECTED] - Sat Jul 02 11:28:26 2005]:
On Sat, Jul 02, 2005 at 10:03:42AM -, houstorx @ rpc142. cs. man.
ac. uk wrote:
Lvalue functions don't work properly when running under the
debugger (perl -d). For example, the following code:
my $x = 'badbad';
sub x :lvalue {$x}
x = good;
print The value of \$x is: $x\n;
prints 'The value of $x is: badbad' when you run it with the
debugger. This happens with every version of perl that I've
tested, including 5.8.6 and 5.9.2.
The reason is that when running under the debugger, all function calls
are
wrapped by a call to BD::sub, which does (in outline)
if (wantarray)
@res = $sub;
...
@res;
}
else {
$res = $sub;
...
$res;
}
and of course that blows away the lvalue-ness of the value returned by
the
sub.
Can't see an easy way op fixing it.
Actually, this is a old known bug. Merging this one with RT #7013.
[perl #30778] localizing $foo, then glob-aliasing to an LVALUE segfaults when trying to restore.
[EMAIL PROTECTED] - Thu Jul 22 14:44:50 2004]:
On Thu, Jul 22, 2004 at 03:41:59PM +0100, [EMAIL PROTECTED] wrote:
James Mastros (via RT) [EMAIL PROTECTED] wrote:
:Code:
:#!/usr/bin/perl
:use warnings;
:use Devel::Peek;
:$|=1;
:
:{
:local $foo;# Local *foo instead, and it works.
:my $x; # Only to shut up warnings -- both lexical and
global $x exhibit this behavior
:*foo=\pos($x); # Neccessary
:Dump *foo;
:print Got here\n;
:}
:print Got here\n;
:__DATA__
Segfault confirmed on bleadperl (@23061):
It occurs because when unlocalizing, any magic associated with the
local
value is copied back to the restored value, but the extra fields
associated with PVLV types, such as LvTARG, aren't copied across.
This results in the restored value being a mangled PVLV (with null
LvTARG). When SvSETMAGIC() is called on this PVLV, it blows up.
Now, I'm not sure why magic is copied across to the restored value; I
guess it's something to do with preserving the magicalness of magic
vars
like $/ across localizations? But I'd have thought that for that, it's
important to copy the magic forward in the local() rather than copying
back during the leave_scope() ???
Anyway, I guess the fix is to not copy across the magic if it's a PVLV
in leave_scope().
Dave.
Again, not sure what the fix was, but it works just fine in bleadperl.
[perl #8277] { local $ENV{TZ} = 'foo' } does not restore timezone if $ENV{TZ}
[EMAIL PROTECTED] - Thu Jan 17 06:26:04 2002]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.33 running under perl v5.6.1.
-
[Please enter your report here]
Not sure how platform-specific this is, but if $ENV{TZ} is undefined,
'local $ENV{TZ}' does not restore the original libc timezone at the end
of
the scope. On my system,
$ perl -le 'print scalar localtime; { local $ENV{TZ} = 'GMT' }
print scalar localtime'
Produces:
Thu Jan 17 17:23:07 2002
Thu Jan 17 22:23:07 2002
This appears to have been fixed sometime prior to Perl 5.8.7.
[EMAIL PROTECTED]:~/perl-current$ ./perl -le 'print scalar localtime; { local
$ENV{TZ} = 'GMT' } print scalar localtime'
Mon Jul 4 23:56:40 2005
Mon Jul 4 23:56:40 2005
[perl #36423] Perl 5.6.1: Can't call method tid on an undefined value at c:/perl/lib/Carp/Heavy.pm line 232.
Since this module is not a core part of Perl, I'd suggest discussing this problem with the module's maintainer Ivan Kohler at [EMAIL PROTECTED].
[PATCH]Re: [perl #36417] IO::Handle::getline() doco should note an important difference from $io
On Wed, Jun 29, 2005 at 02:25:49PM +0200, demerphq wrote:
On 6/29/05, Michael G Schwern [EMAIL PROTECTED] wrote:
On Tue, Jun 28, 2005 at 06:25:31PM -, Justin Mason wrote:
However, there is one key difference: while ($io) and while
($io-getline) ha ve different behaviour.If the last line of an
input file
contains 0 (with no trailing newline), while ($io) will read it and
perform an iteration of the while loop, but while ($io-getline) will
read
it, consider it a false value, and instead break out of the while loop.
Confirmed. while(FH) must have some sort of special case to consider
0 true to avoid this sort of gotcha.
while (FH) {
is documented to be equivelent to
while (defined($_=FH)) {
in perlvar I/O Operators.
--
perl -Mre=debug -e /just|another|perl|hacker/
Then, how does the following sound to everyone...
--- ext/IO/lib/IO/Handle.pm.old Sun Apr 4 08:32:35 2004
+++ ext/IO/lib/IO/Handle.pm Wed Jun 29 08:34:48 2005
@@ -117,7 +117,10 @@
This works like $io described in Lperlop/I/O Operators
except that it's more readable and can be safely called in a
-list context but still returns just one line.
+list context but still returns just one line. If used within a
+conditional statement, however, you will need to emulate the
+functionality of $io with Cdefined($x = $io-getline) where
+C$x is a scalar you have previously defined.
=item $io-getlines
Steve Peters
[EMAIL PROTECTED]
Re: [PATCH]Re: [perl #36417] IO::Handle::getline() doco should note an important difference from $io
On Wed, Jun 29, 2005 at 10:24:29AM -0400, Ronald J Kimball wrote: Why not just use $_ there? Not only does that emulate the actual behavior of $io, but then you don't need the confusing note about $x. Well, I was hoping to confuse ;). --- ext/IO/lib/IO/Handle.pm.old Sun Apr 4 08:32:35 2004 +++ ext/IO/lib/IO/Handle.pm Wed Jun 29 10:43:47 2005 @@ -117,7 +117,9 @@ This works like $io described in Lperlop/I/O Operators except that it's more readable and can be safely called in a -list context but still returns just one line. +list context but still returns just one line. If used within a +conditional statement, however, you will need to emulate the +functionality of $io with Cdefined($_ = $io-getline). Steve Peters [EMAIL PROTECTED]
Re: [PATCH]Re: [perl #36417] IO::Handle::getline() doco should note an important difference from $io
On Wed, Jun 29, 2005 at 11:56:10PM +0100, Dave Mitchell wrote: On Wed, Jun 29, 2005 at 06:46:49PM -0400, Ronald J Kimball wrote: not within any old conditional statement, only as the sole contents of a *while* condition. Or the conditional in a C-style for loop, I believe. Indeed. So, indeed, I hope that the third time is the charm... --- ext/IO/lib/IO/Handle.pm.old Sun Apr 4 08:32:35 2004 +++ ext/IO/lib/IO/Handle.pm Wed Jun 29 21:46:44 2005 @@ -117,7 +117,9 @@ This works like $io described in Lperlop/I/O Operators except that it's more readable and can be safely called in a -list context but still returns just one line. +list context but still returns just one line. If used as the conditional +within a Cwhile or C-style Cfor loop, however, you will need to +emulate the functionality of $io with Cdefined($_ = $io-getline). =item $io-getlines Steve Peters [EMAIL PROTECTED]
[PATCH] strlcat() and strlcpy
Well, my ADD has caused me to refocus my attention back to the issues
of strlcat() and strlcpy(). I started some conversion several months
ago, but other things have interrupted me. Late last week, I took
a look at what I had started, and wasn't exceptionally impressed with
what I saw. Although my initial patch did provide the benefits of
strlcat() and strlcpy() to the core and module writers on systems with
those functions in libc, elsewhere, people were still out in the
cold.
The attached patch helps to fix that. It adds two new functions to
util.c: Perl_my_strlcat() and Perl_my_strlcpy(). These functions
provide all the functionality that strlcat() and strlcpy() provide
in systems where these functions are not included in libc. The
code for these functions were originally released as part of Cinn,
but the code for strlcat() and strlcpy() within Cinn was released
into the public domain. The code required few modifications to
be worked into Perl, but are mostly as Russ Allbery original had
written them. Thanks Russ!
The patch included was tested on Linux, with and without ithreads and
DEBUGGING, and passed all of its tests.
Steve Peters
[EMAIL PROTECTED]
--- doio.c.old 2005-06-23 05:49:45.0 -0500
+++ doio.c 2005-06-27 09:37:50.807826128 -0500
@@ -274,17 +274,10 @@
}
mode[0] = 'w';
writing = 1;
-#ifdef HAS_STRLCAT
if (out_raw)
strlcat(mode, b, PERL_MODE_MAX);
else if (out_crlf)
strlcat(mode, t, PERL_MODE_MAX);
-#else
- if (out_raw)
- strcat(mode, b);
- else if (out_crlf)
- strcat(mode, t);
-#endif
if (num_svs 1) {
fp = PerlProc_popen_list(mode, num_svs, svp);
}
@@ -312,17 +305,10 @@
}
writing = 1;
-#ifdef HAS_STRLCAT
if (out_raw)
strlcat(mode, b, PERL_MODE_MAX);
else if (out_crlf)
strlcat(mode, t, PERL_MODE_MAX);
-#else
- if (out_raw)
- strcat(mode, b);
- else if (out_crlf)
- strcat(mode, t);
-#endif
if (*type == '') {
duplicity:
dodup = PERLIO_DUP_FD;
@@ -440,17 +426,10 @@
else if (*type == IoTYPE_RDONLY) {
for (type++; isSPACE(*type); type++) ;
mode[0] = 'r';
-#ifdef HAS_STRLCAT
if (in_raw)
strlcat(mode, b, PERL_MODE_MAX);
else if (in_crlf)
strlcat(mode, t, PERL_MODE_MAX);
-#else
- if (in_raw)
- strcat(mode, b);
- else if (in_crlf)
- strcat(mode, t);
-#endif
if (*type == '') {
goto duplicity;
}
@@ -501,17 +480,10 @@
TAINT_PROPER(piped open);
mode[0] = 'r';
-#ifdef HAS_STRLCAT
if (in_raw)
strlcat(mode, b, PERL_MODE_MAX);
else if (in_crlf)
strlcat(mode, t, PERL_MODE_MAX);
-#else
- if (in_raw)
- strcat(mode, b);
- else if (in_crlf)
- strcat(mode, t);
-#endif
if (num_svs 1) {
fp = PerlProc_popen_list(mode,num_svs,svp);
@@ -538,17 +510,10 @@
;
mode[0] = 'r';
-#ifdef HAS_STRLCAT
if (in_raw)
strlcat(mode, b, PERL_MODE_MAX);
else if (in_crlf)
strlcat(mode, t, PERL_MODE_MAX);
-#else
- if (in_raw)
- strcat(mode, b);
- else if (in_crlf)
- strcat(mode, t);
-#endif
if (*name == '-' name[1] == '\0') {
fp = PerlIO_stdin();
@@ -1532,19 +1497,11 @@
char flags[PERL_FLAGS_MAX];
if (strnEQ(cmd,PL_cshname,PL_cshlen)
strnEQ(cmd+PL_cshlen, -c,3)) {
-#ifdef HAS_STRLCPY
- strlcpy(flags, -c, PERL_FLAGS_MAX);
-#else
- strcpy(flags,-c);
-#endif
+ strlcpy(flags, -c, PERL_FLAGS_MAX);
s = cmd+PL_cshlen+3;
if (*s == 'f') {
s++;
-#ifdef HAS_STRLCPY
strlcat(flags, f, PERL_FLAGS_MAX);
-#else
- strcat(flags,f);
-#endif
}
if (*s == ' ')
s++;
--- embed.fnc.old 2005-06-24 09:30:49.0 -0500
+++ embed.fnc 2005-06-25 08:35:49.0 -0500
@@ -488,6 +488,12 @@
Ap |void |my_setenv |const char* nam|const char* val
Ap |I32|my_stat
Ap |char * |my_strftime|const char *fmt|int sec|int min|int hour|int
mday|int mon|int year|int wday|int yday|int isdst
+#if !defined(HAS_STRLCAT)
+Ap |size_t |my_strlcat |char *dst|const char* src|size_t size
+#endif
+#if !defined(HAS_STRLCPY)
+Ap |size_t |my_strlcpy |char *dst|const char* src|size_t size
+#endif
#if defined(MYSWAP)
ApPa |short |my_swap|short s
ApPa |long |my_htonl |long l
[PATCH] Silence warning in op.c
I ran into a new warning in op.c this morning. op.c: In function `Perl_newCONSTSUB': op.c:4605: warning: null argument where non-null required (arg 1) This warning is caused by a call to Perl_newXS() where the first parameter is set by embed.fnc to be non-null. However, since the first couple of lines of code in Perl_newXS() involve what to do if the first parameter is null, this seems unnecessary. The patch below silences the warning. Since its a patch to embed.fnc, a regen will be necessary after applying the patch. Steve Peters [EMAIL PROTECTED] --- embed.fnc.old 2005-06-23 16:59:08.0 -0500 +++ embed.fnc 2005-06-24 09:32:40.617371712 -0500 @@ -513,7 +513,7 @@ Apa|OP*|newSLICEOP |I32 flags|OP* subscript|OP* listop Apa|OP*|newSTATEOP |I32 flags|char* label|OP* o Ap |CV*|newSUB |I32 floor|OP* o|OP* proto|OP* block -Apd|CV*|newXS |NN const char* name|XSUBADDR_t f|NN const char* filename +Apd|CV*|newXS |const char* name|XSUBADDR_t f|NN const char* filename Apda |AV*|newAV Apa|OP*|newAVREF |NN OP* o Apa|OP*|newBINOP |I32 type|I32 flags|OP* first|OP* last
Re: Another bcc32 warning caused by change 24945
On Fri, Jun 24, 2005 at 06:06:51PM +0100, Steve Hay wrote:
24945 changed the second arg of Perl_magic_getarylen from MAGIC* to
const MAGIC*, which now makes bcc32 complain:
..\globals.c:
Warning W8075 ..\perl.h 4180: Suspicious pointer conversion
(It seems to have got its line numbers confused too. cpp32 output shows:
/* ..\perl.h 4180: */const MGVTBL PL_vtbl_arylen =
{Perl_magic_getarylen,Perl_magic_setarylen,0,0,0,0,0};
)
Are the other Perl_magic_get*() functions going to get their MAGIC*'s
constified too?
If so then the problem will go away when struct mgvtbl is updated to
match in mg.h. If not then we need to think of some other way to
suppress the new warning.
I suspect it may be related to the warning I'm seeing as well.
In file included from globals.c:35:
perl.h:4170: warning: initialization from incompatible pointer type
This also points to ...
4178 MGVTBL_SET(
4179 PL_vtbl_arylen,
4180 MEMBER_TO_FPTR(Perl_magic_getarylen),
4181 MEMBER_TO_FPTR(Perl_magic_setarylen),
4182 NULL,
4183 NULL,
4184 NULL,
4185 NULL,
4186 NULL
4187 );
Steve Peters
[EMAIL PROTECTED]
[perl #34677] perl-5.8.5 install error
[EMAIL PROTECTED] - Thu Apr 21 15:47:26 2005]:
On Thu, Apr 07, 2005 at 01:16:02AM -0400, mnow wrote:
Andy,
Upon running PERL_CORE, I recieved this error
1..7
ok 1 - use Net::hostent;
not ok 2 - gethost('localhost')
# Can't continue without working gethost:
It's most likely you haven't got an entry for 'localhost' in /etc/hosts
The odd thing is I do not remember there being a command of gethost
or is gethost a function of Perl?
It's a Perl library function.
I was able to replicate this problem by removing the localhost entries
from my /etc/hosts file.
[perl #34301] [PATCH] IO::Socket calls getpeername far too often
[dint - Thu Jun 02 04:35:41 2005]:
This is a proposal for bug #34301, IO::Socket calls getpeername
far too often.
CC: [EMAIL PROTECTED]
Subject: IO::Socket calls getpeername far too often
Date: Tue, 1 Mar 2005 11:33:10 -0500
To: [EMAIL PROTECTED]
From: Brian Caswell [EMAIL PROTECTED]
[snip]
The peername sub can use a cache of the peername, but it only uses the
cache if getpeername fails. Shouldn't it use the cache first, and only
look up the name if the cache doesn't exist?
The patch below introduces this behaviour. The peername() method
now caches the peername retrieved from getpeername(). Both close()
and shutdown() invalidate the cache.
A new method close() is introduced in IO::Socket to this end and
close($sock) in IO::Socket::INET is replaced with $sock-close() to
enforce the cache invalidation.
I am not sure if all this should really be done. Can someone please
carefully re-think it?
The send sub currently calls getpeername once or twice. If the peer
wasn't
passed in as an arguement, send calls peername.
this is cached now
Then later, send calls
getpeername to decide if it should pass the peer to Socket's send.
If the
send is successful, then the peername is cached, but the cache isn't
used
in later sends.
The purpose of this call to getpeername() is not to find out the
actual
peername but to know if the socket is still connected. This is needed
for
the subsequent call to Socket's send(). I therefore think that
this call
to getpeername() cannot be avoided.
I tried making the above changes to IO::Socket in perl-current (rsynced
from
rsync://ftp.linux.activestate.com/perl-current/ this morning). The
change
worked fine for UDP, but t/io_udp.t hangs at test 6.
$ diff -ur
/opt/perl32/lib/5.8.7/sun4-solaris-thread-multi-64int/IO/Socket.pm
Socket.pm
--- /opt/perl32/lib/5.8.7/sun4-solaris-thread-multi-64int/IO/Socket.pm
Wed
Jun 1 16:20:36 2005
+++ Socket.pm Thu Jun 2 13:46:18 2005
@@ -141,6 +141,13 @@
$err ? undef : $sock;
}
+sub close {
+@_ == 1 or croak 'usage: $sock-close()';
+my $sock = shift;
+${*$sock}{'io_socket_peername'} = undef;
+$sock-SUPER::close();
+}
+
sub bind {
@_ == 2 or croak 'usage: $sock-bind(NAME)';
my $sock = shift;
@@ -195,9 +202,7 @@
sub peername {
@_ == 1 or croak 'usage: $sock-peername()';
my($sock) = @_;
-getpeername($sock)
- || ${*$sock}{'io_socket_peername'}
- || undef;
+${*$sock}{'io_socket_peername'} ||= getpeername($sock);
}
sub connected {
@@ -239,6 +244,7 @@
sub shutdown {
@_ == 2 or croak 'usage: $sock-shutdown(HOW)';
my($sock, $how) = @_;
+${*$sock}{'io_socket_peername'} = undef;
shutdown($sock, $how);
}
$ diff -ur /opt/perl32/lib/5.8.7/IO/Socket/INET.pm INET.pm
--- /opt/perl32/lib/5.8.7/IO/Socket/INET.pm Wed Jun 1 16:20:36 2005
+++ INET.pm Thu Jun 2 13:21:29 2005
@@ -81,7 +81,7 @@
local($!);
my $title = ref($sock).: ;
$@ = join(, $_[0] =~ /^$title/ ? : $title, @_);
- close($sock)
+ $sock-close()
if(defined fileno($sock));
}
$! = $err;
This patch appears to have been warnocked. Has anyone looked into it at
all?
[perl #34346] core dump with unmatched empty quotes
I came across something similar to this the other day, using a recent gentoo ebuild of 5.8.6 (I /think/ it was 5.8.6-r1, but it might have been r2 or r3); triggered a segfault with: perl -e 'print if $. = 1' Upgrading to -r4 fixed the issue. FYI, HTH, HAND. =) Great, problem resolved.
[perl #32197] Re: [uClibc] perl-5.8.5: non-portable code causes build failure on uclibc
[stmpeters - Thu Nov 04 08:09:26 2004]: [EMAIL PROTECTED] - Thu Oct 28 10:45:31 2004]: On Thu, Oct 28, 2004 at 10:42:49AM +0300, Denis Vlasenko wrote: This part of perl source code caused build failure on uclibc. perl-5.8.5/perlio.c: See http://www.uclibc.org/lists/uclibc/2004-March/008512.html Manuel Rather than have everyone track it down, here is the proposed patch from that mailing list email. --- perl-5.8.2/perlio.c-dist 2003-12-03 14:30:24.0 -0700 +++ perl-5.8.2/perlio.c 2003-12-03 14:32:10.0 -0700 @@ -2824,7 +2824,15 @@ /* XXX this could use PerlIO_canset_fileno() and * PerlIO_set_fileno() support from Configure */ -# if defined(__GLIBC__) +# if defined(__UCLIBC__) +/* uClibc must come before glibc because it defines __GLIBC__ as well. */ +# if defined(__MASK_READING) +f-__filedes = -1; +# else +f-filedes = -1; +# endif +return 1; +# elif defined(__GLIBC__) /* There may be a better way for GLIBC: - libio.h defines a flag to not close() on cleanup */ This was included with change #23732.
[perl #33770] eval { /(?{die})/ }; $@; causes segfault on 5.9.1
[EMAIL PROTECTED] - Tue Jan 11 18:15:56 2005]:
The following code generates a segfault:
eval { /(?{die})/ }; $@
Note that the $@ is necessary as it doesn't segfault without it.
If you omit the reference to $@ it doesn't segfault but it doesn't
appear to execute any code after the eval block. For example,
perl -eeval { /(?{die})/ }; print 'foo'
produces no output, but doesn't segfault.
This is repeatable with the current blead. Backtrace and -DstvP output
below.
#0 0x080e6902 in Perl_pp_gvsv (my_perl=0x81b6008) at pp_hot.c:61
61 PUSHs(GvSV(cGVOP_gv));
(gdb) bt
#0 0x080e6902 in Perl_pp_gvsv (my_perl=0x81b6008) at pp_hot.c:61
#1 0x080cbe61 in Perl_runops_debug (my_perl=0x81b6008) at dump.c:1600
#2 0x08066c3f in S_run_body (my_perl=0x81b6008, oldscope=1) at perl.c:2038
#3 0x080666b5 in perl_run (my_perl=0x81b6008) at perl.c:1972
#4 0x0806046d in main (argc=2, argv=0xbab4, env=0xbac0) at
perlmain.c:103
[EMAIL PROTECTED]:~/perl-current$ ./perl -DstvP -wle'eval { /(?{die})/ }; print
$@'
Use of uninitialized value.
filter_add func 806ce46 ()
Use of uninitialized value.
filter_read 0: via function 81b6d88 ()
Use of uninitialized value at -e line 1.
filter_read 0: via function 81b6d88 ()
filter_del func 806ce46
EXECUTING...
STACK 0: MAIN
(-e:0) enter
STACK 0: MAIN
CX 0: BLOCK =
(-e:0) nextstate
STACK 0: MAIN
CX 0: BLOCK =
(-e:1) entertry
STACK 0: MAIN
CX 0: BLOCK =
CX 1: EVAL =
retop=nextstate
(-e:1) nextstate
STACK 0: MAIN
CX 0: BLOCK =
CX 1: EVAL =
retop=nextstate
STACK 0: MAIN
CX 0: BLOCK =
CX 1: EVAL =
retop=nextstate
(-e:1) match
Use of uninitialized value $_ in pattern match (m//) at -e line 1.
STACK 0: MAIN
CX 0: BLOCK =
CX 1: EVAL =
retop=nextstate
(-e:1) nextstate
STACK 0: MAIN
CX 0: BLOCK =
CX 1: EVAL =
retop=nextstate
((re_eval 1):1) pushmark
STACK 0: MAIN
CX 0: BLOCK =
CX 1: EVAL = *
retop=nextstate
((re_eval 1):1) die
STACK 0: MAIN
CX 0: BLOCK =
(-e:1) nextstate
STACK 0: MAIN
CX 0: BLOCK =
(-e:1) pushmark
STACK 0: MAIN
CX 0: BLOCK = *
(-e:1) gvsvSegmentation fault (core dumped)
[perl #32745] [PATCH] Perl (all versions) hides write error, with patch
[meyering - Wed Dec 01 11:14:10 2004]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.9.1.
-
Sometimes, closing a Perl file handle succeeds even though there have
been write errors via that handle. This bug appears to affect every
version of perl from 5.005_04 to 5.9.1. I didn't build/test versions
earlier than 5.005_04, but the doio.c:do_close function in 5.003 looks
like it has the same problem.
Here's a quick demo that depends on two things:
- you have a /dev/full device (Linux, HPUX, MaxOS-X/Darwin)
- 131072 is a multiple of your system's I/O buffer size
perl -e 'print x x 131072; close STDOUT or die $!\n' \
/dev/full 2 /dev/null echo fail || echo ok
It prints `fail' because at least one write system call failed and
Perl's
`close' mistakenly succeeded. It would print `ok' for any size output
other than a multiple of the output buffer size. On the Linux systems
I've checked, that size is 4096. On a ppc/Darwin (7.5.0) system I
tested,
the buffer size was 131072.
This means that if your Perl script happens to write precisely the
wrong number of bytes to a full or corrupted disk or to a closed file
descriptor, even if you dutifully check for success when closing the
file handle, the error will go undetected.
Here's another demo. Notice that it fails (as it should) for sizes
131071 and 131073, but not for output of size 131072.
$ perl -e 'print x x 131071; close STDOUT or die $!\n'
/dev/full
No space left on device
[Exit 28]
$ perl -e 'print x x 131072; close STDOUT or die $!\n'
/dev/full
$ perl -e 'print x x 131073; close STDOUT or die $!\n'
/dev/full
No space left on device
[Exit 28]
After applying the patch below, the problematic case (with size being
a multiple of 4096 in my case), now fails, as it should:
$ ./perl -e 'print x x 131072; close STDOUT or die $!\n'
/dev/full
No space left on device
[Exit 28]
On a Solaris 5.9 system, which lacks /dev/full, I demonstrated
the failure with the following small script that invokes perl with
stdout closed. All invocations of perl should evoke the
`Bad file number' error. But note that on some systems the
closed-stdout test succeeds (perl detects the error) even though
the write-to-/dev/full test fails.
#!/bin/sh
n=1024
for i in 1 2 3 4 5 6; do
echo $n
perl -e 'print x x '$n'; close STDOUT or die $!\n' -
n=`expr 2 \* $n`
done
Here's the output:
1024
Bad file number
2048
Bad file number
4096
Bad file number
8192
Bad file number
16384
32768
This patch fixes the bug and induces no new failures in any of
these versions:
5.005_04
5.6.2
5.8.6
5.9.1
2004-11-30 Jim Meyering [EMAIL PROTECTED]
* doio.c (Perl_io_close): Make the return value depend not only on
the
success of the close itself, but also on whether the output stream
had
a previous error.
--- doio.c.orig 2004-11-29 19:41:05.747199832 +0100
+++ doio.c2004-12-01 08:39:53.106764936 +0100
@@ -1014,11 +1014,14 @@ Perl_io_close(pTHX_ IO *io, bool not_imp
retval = TRUE;
else {
if (IoOFP(io) IoOFP(io) != IoIFP(io)) { /* a socket */
- retval = (PerlIO_close(IoOFP(io)) != EOF);
+ bool prev_err = PerlIO_error(IoOFP(io));
+ retval = (PerlIO_close(IoOFP(io)) != EOF !prev_err);
PerlIO_close(IoIFP(io));/* clear stdio, fd already
closed */
}
- else
- retval = (PerlIO_close(IoIFP(io)) != EOF);
+ else {
+ bool prev_err = PerlIO_error(IoIFP(io));
+ retval = (PerlIO_close(IoIFP(io)) != EOF !prev_err);
+ }
}
IoOFP(io) = IoIFP(io) = Nullfp;
}
Does anyone have any objections to this patch?
[PATCH] for/foreach nit in perlsyn.pod
To help others in avoiding the same embarassing moment I had last week, below is a patch to help to help clarify the actual functionality of for and foreach. I'm also working on a slightly larger patch to merge the For loop and Foreach loop sections of the documentation to help emphasize the fact that there is no difference in the functionality of the two. Steve Peters [EMAIL PROTECTED] --- perlsyn.pod.old Mon Jun 20 08:42:00 2005 +++ perlsyn.pod Mon Jun 20 08:43:53 2005 @@ -200,6 +200,9 @@ LABEL while (EXPR) BLOCK LABEL while (EXPR) BLOCK continue BLOCK LABEL for (EXPR; EXPR; EXPR) BLOCK +LABEL for VAR (LIST) BLOCK +LABEL for VAR (LIST) BLOCK continue BLOCK +LABEL foreach (EXPR; EXPR; EXPR) BLOCK LABEL foreach VAR (LIST) BLOCK LABEL foreach VAR (LIST) BLOCK continue BLOCK LABEL BLOCK continue BLOCK
[perl #9741] possible problem with File::Find
[EMAIL PROTECTED] - Sat Jun 18 02:28:41 2005]: -BEGIN PGP SIGNED MESSAGE- Moin, Steve Peters [EMAIL PROTECTED] wrote: On Fri, Jun 17, 2005 at 07:55:04PM -0500, Steve Peters wrote: On Fri, Jun 17, 2005 at 09:44:20AM -0700, Warren L Dodge wrote: [snip] The below patch has been tested on a fresh bleadperl on Win32 and passed its tests. It also clears up the bugs seen above. Also included is a small doc nit for File::Find and a version bump. I am not sure, but couldn't all the platform-specific file/path/dir juggling be done by File::Find just using File::Spec? Best wishes, Tels Because, unfortunately, File::Spec doesn't deal with these sorts of issues on Win32 effectively. For example, on Win32, the rootdir is considered to be /. That's fine, but since the typical Win32 file system is spread over multiple volumes, this is not particular helpful if you are looking across multiple volumes. The extra processing is needed so that users can tell the difference between C:/foo and F:/foo.
[perl #36232] Win32: cannot create hard links on mounted network share
[mkoeppe - Thu Jun 09 12:01:32 2005]: This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.35 running under perl v5.8.6. With ActivePerl 5.8.6.811, creating a hard link on a local NTFS formatted drive (Win2000) works as expected, but it fails on a mounted network share (Win2003 server, of course the underlying filesystem is NTFS, too). The hardlink can be created independantly of ActivePerl with Interix tools, however, on both the local disk and on the mounted share as well. Perl 5.8.7 doesn't fix this. More details and a suggestion for a fix can be found on ActiveState's bug number 39027 at http://bugs.activestate.com/show_bug.cgi?id=39027 I first reported it there, but then found, that the responsible source code can be found within http://www.cpan.org/src/stable.tar.bz2 so it might not be solely related to ActiveState. Have you tried the module Win32::Hardlink?
[perl #30507] FindBin::Bin 1.44 returns path with terminating slash
[jpo - Fri Jun 10 06:40:59 2005]: Hi, This problem (trailing slash) is caused by a patch in the Fedora/RedHat perl package. The patch in question - perl-5.8.3-findbin-selinux.patch - has been replaced by a new one - perl-5.8.6-findbin-selinux.patch - which is much less intrusive. The new patch - perl-5.8.6-findbin-selinux.patch - exists in the FC4 perl package and has also been accepted upstream: http://public.activestate.com/cgi-bin/perlbrowse?patch=24753 Summary: 1) This is not a problem in the perl core module FindBin.pm 2) It is caused by an external patch applied to the Fedora/RedHat perl package ( 5.8.3-17 = perl rpm 5.8.6-12 ) Relevant changelog entries in the Fedora/RedHat perl specfile: ... * Sat May 14 2005 Jose Pedro Oliveira jpo at di.uminho.pt - 3:5.8.6-12 - New findbin-selinux patch: it now passes the FindBin.t tests (patch28 replaces patch23). #118877 #127023 - Remove 5.8.2 ABI compat (#154295 comments 6 and 7). ... * Sat Apr 03 2004 Colin Walters [EMAIL PROTECTED] 3:5.8.3-17 - Apply patch to fix FindBin module when access to cwd is disallowed, should solve the MRTG/SELinux cron spam issue ... Regards, jpo Thanks for the infomation! I guess to solve the problem seen by the original poster, the choices would be to use a pristine Perl that you compile by hand, or upgrade to the most recent Perl RPM.
[perl #9741] possible problem with File::Find
[EMAIL PROTECTED] - Sun Jun 23 04:38:19 2002]:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.33 running under perl v5.6.1.
-
[Please enter your report here]
I am using the Find::Find routine to scan a tree of files. It has
worked fine until I tried something on a PC
find ( $routine_ref , directory ) is the form a use.
When the directory is something like c:/temp/work/dir all seems to
work fine.
I made a change to allow C:/ as the directory and find seems to stop
working properly. All the files it finds have no directory appended to
them so they all look like c:/file
Looking down through the find code I see
$top_item =~ s|/\z|| unless $top_item eq '/';
perhaps this need to allow for x:/ also on a pc
With the following script
#!perl -w
use strict;
use File::Find;
sub wanted {
return if ! -f;
print $File::Find::name\n;
}
find \wanted, C:/;
I was not able to duplicate your problem with either Perl 5.8.6 or
5.6.1. It appears that this problem has been resolved.
[perl #30406] File Find anomaly under windows
[EMAIL PROTECTED] - Tue Jun 22 08:14:07 2004]:
I am not sure if it is a bug or a feature!
I have found that when using File::Find on a windows system (Apache,
ActivePerl) and taint-mode enabled, the colon in the Windows path causes
the default untaint_pattern to fail...
Should I just add a colon to the untaint_pattern option when I call
find? (e.g. untaint_pattern = qr|^([EMAIL PROTECTED]/:]+)$| )
Should there be a windows option in setting the default
untaint_pattern in File::Find?
I have tried searching for some sort of comment regarding this, but
have not found it anywhere.
Thanks,
David
I'm personally not very comfortable with changing the default
untaint_pattern, but you can feel free to change it on your own to a
value appropritate to your situation by setting the untaint_pattern in
the hash you pass in.
#!perl -w
use strict;
use File::Find;
sub wanted {
return if ! -f;
print $File::Find::name\n;
}
my %options;
$options{untaint_pattern} = qr|^([EMAIL PROTECTED]/:]+)$|;
$options{wanted} = \wanted;
$options{untaint} = 1;
find \%options, C:/;
