[27068] in Perl-Users-Digest
Perl-Users Digest, Issue: 8968 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 17 18:05:47 2006
Date: Fri, 17 Feb 2006 15:05:04 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 17 Feb 2006 Volume: 10 Number: 8968
Today's topics:
Re: Inconsistent returns from piped open <ced@blv-sam-01.ca.boeing.com>
Need advice on debugging malloc bug (XML::Parser::Expat <socyl@987jk.com.invalid>
Re: Puzzled over rgexp (Rick Scott)
Re: The inverse problem: generate all instances of a re (See Website For Email)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 17 Feb 2006 22:40:59 GMT
From: Charles DeRykus <ced@blv-sam-01.ca.boeing.com>
Subject: Re: Inconsistent returns from piped open
Message-Id: <IuusCA.FE1@news.boeing.com>
fishfry wrote:
> In article <20060216233124.621$mN@newsreader.com>, xhoster@gmail.com
> wrote:
>
>> fishfry <fishfry@your-mailbox.com> wrote:
>>> #!/usr/bin/perl
>>> use strict;
>>>
>>> # 1. The open() call returns false.
>>> my $x = open(XX, "| junk");
>>> print "x = $x\n";
>> Perl tries to execute junk. It fails.
>>
>>> # 2. The open() call returns true.
>>> my $y = open(YY, "| junk > foozle");
>>> print "y = $y\n";
>> This contains shell metacharacters, so perl tries to start
>> up a shell. It succeeds, and returns the pid of the shell it
>> started. The shell turns around and tries to execute junk, and of
>> course it fails. But the shell's failure is not perl's failure.
>>
>
> Very sensible explanation, thanks. Didn't realize that the output
> redirect caused an intervening shell to be created, whereas the first
> case didn't. I think I'm going to have to explicitly fork/exec to get
> control of the process creation.
There are some caveats - perldoc IPC::Open3 - but alternatively you may
be able to use something simpler:
use IPC::Open3;
my $pid = open3( \*W, \*R, \*E ,'./junk > froozle');
die "open fork failed: $!" unless $pid;
die "open error: ",<E> unless eof E;
--
Charles DeRykus
------------------------------
Date: Fri, 17 Feb 2006 20:31:10 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: Need advice on debugging malloc bug (XML::Parser::Expat)
Message-Id: <dt5bqe$cis$1@reader2.panix.com>
I have run out of things to try to fix a particular bug, and I'm
hoping some of you may be able to give me some ideas.
The bug happens only when the program is run inside the Perl debugger
(which I do often; the Perl debugger is an integral part of my
development environment).
To reproduce the bug, the program must first invoke
XML::Parser::Expat::ParseString to parse some XML. Once the parsing
finishes, if I attempt to match a capture-containing regexp to a
string obtained from the match, one of a few bad things happen:
either the capture (e.g. $1) will contain garbage; or the program
will die with a "panic: malloc" error; or the program will hang;
or the program will die with an "Out of memory!" error.
The following snippet illustrates the sequence I just described
(but before you "try this at home", read below):
use strict;
use warnings;
use XML::Parser::Expat;
my $xml = '<?xml version="1.0"?><Foo></Foo>';
my $content = '';
my $parser = XML::Parser::Expat->new();
$parser->setHandlers(Start => sub { $content .= ">@_<" });
XML::Parser::Expat::ParseString($parser->{Parser}, $xml);
print "$content\n"; # shows that the parsing happend
$content =~ /([a-z]+)/; # BOOM!
print "OK\n";
__END__
% perl -d expat_bug.pl
...
main::(expat_bug.pl:6): my $xml = '<?xml version="1.0"?><Foo></Foo>';
DB<1> r
>XML::Parser::Expat=HASH(0x8342150) Foo<
panic: malloc at expat_bug.pl line 15.
at expat_bug.pl line 15
In this case, the outcome was the "panic: malloc" error, but this
is not always the case. Innocuous-seeming changes in the source
code can lead to one of the other outcomes I listed.
Unfortunately, I have not been able to reproduce this bug anywhere
outside our system (Linux SuSE). (In other words, if I don't fix
this problem, probably no one will.)
I have re-built and re-installed perl, XML::Parser, and libexpat,
and still the problem persists.
I looks like the root of the bug is that some part of memory is
being overwritten by mistake (a rather typical occurrence with C
programs).
What tool would you recommend to catch something like this?
Any other suggestions would be much appreciated.
kj
PS For the sake of completeness, I give details of my setup below.
Also note that the details below are only one of the several setups
I've tried. (E.g. I've compiled and tried different versions of
perl, with different options, etc.)
% uname -ar
Linux luna 2.6.11.4-21.10-smp #1 SMP Tue Nov 29 14:32:49 UTC 2005 i686 i686 i386 GNU/Linux
% perl -V
Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
Platform:
osname=linux, osvers=2.6.9, archname=i586-linux-thread-multi
uname='linux g226 2.6.9 #1 smp tue jun 28 14:58:56 utc 2005 i686 i686 i386 gnulinux '
config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -Doptimize=-O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -g -Wall -pipe'
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=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -g -Wall -pipe',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe'
ccversion='', gccversion='3.3.5 20050117 (prerelease) (SUSE Linux)', 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 =''
libpth=/lib /usr/lib /usr/local/lib
libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.4'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Locally applied patches:
SPRINTF0 - fixes for sprintf formatting issues - CVE-2005-3962
Built under linux
Compiled at Dec 17 2005 03:23:29
%ENV:
PERL5LIB="/home/jones/local/lib/perl5"
PERL5_CPANPLUS_CONFIG="/home/jones/.cpanplus/config"
PERL_RL="Perl"
@INC:
/home/jones/local/lib/perl5/5.8.6/i586-linux-thread-multi
/home/jones/local/lib/perl5/5.8.6
/home/jones/local/lib/perl5/i586-linux-thread-multi
/home/jones/local/lib/perl5
/usr/lib/perl5/5.8.6/i586-linux-thread-multi
/usr/lib/perl5/5.8.6
/usr/lib/perl5/site_perl/5.8.6/i586-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.6
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.6/i586-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.6
/usr/lib/perl5/vendor_perl
.
% perl -MXML::Parser::Expat -le 'print $XML::Parser::Expat::VERSION'
2.34
--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
------------------------------
Date: Fri, 17 Feb 2006 16:04:12 -0000
From: rick@shadowspar.dyndns.org (Rick Scott)
Subject: Re: Puzzled over rgexp
Message-Id: <1fa3.43f5f3fc.4f8fa@shadowspar>
(IanW <whoever@whereever.com> uttered:)
> Can anyone tell me why the following doesn't return "Not standards
> compliant"?
>
> my $em = ',someone@somewhere.com'; # note the comma in fornt of the email
> address
> if ($em =~
> /^(?!\.)[!\#\$%&'*+-\/=?^_`{|}~.a-zA-Z0-9]+(?<!\.)\@(?!\.)[a-zA-Z0-9-.]+$/)
> ...
Just out of curiousity, are you trying to validate the format of
email addresses? If so, you will be far better served by using a CPAN
module than by trying to roll your own.
Mail::RFC822::Address
Email::Valid
perldoc -q 'valid mail'
Rick
--
key CF8F8A75 / print C5C1 F87D 5056 D2C0 D5CE D58F 970F 04D1 CF8F 8A75
A: Because the response should come after the question.
Q: Why is top-posting so annoying?
:Mike Andrews
------------------------------
Date: Fri, 17 Feb 2006 12:50:37 -0800
From: "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com>
Subject: Re: The inverse problem: generate all instances of a regexp
Message-Id: <Iuun8D.1pyH@beaver.cs.washington.edu>
Dr.Ruud wrote:
> Andrei Alexandrescu (See Website For Email) schreef:
>
>> I wonder how this could be done elegantly. Given a regular expression
>> $re, write a function Generate($) that returns a list of all possible
>> strings that could match $re.
>
> http://search.cpan.org/~bowmanbs/Regexp-Genex/lib/Regexp/Genex.pm
Wow, that's exactly what the doctor prescribed... thanks, Dr. Ruud :o).
Andrie
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8968
***************************************
