#28386: UNIVERSAL::VERSION segfaults if $VERSION not defined
David Dyck
I submitted this but via the perlbug tool, but it didn't
show up yet in the p5p mailing list, so I'll post it here
to bring it into conversation.
dd:dcd$ perl -le '$VERSION=1; print main->VERSION'
1
dd:dcd$ perl -le 'print main->VERSION'
Segmentation fault
This can't be the desired behaviour.
I've seen this problem a few times today
perldoc segfaulted because
Pod::Perldoc::find_good_formatter_class
wanted to get the version of Pod::Perldoc::ToMan
(see line 502)
I also had trouble installing Pod-Perldoc-3.12
since it's Makefile.PL PREREQ_PM
require'd Config's VERSION to be defined
More details can be found at
http://rt.perl.org/rt3/Ticket/Display.html?id=28386
The most recent patch to universal.c came from the
rsync server in the file 22668.gz
Change 22668 by rgs@valis on 2004/04/07 08:00:07
Subject: [PATCH] Bleadperl to version 0.37
From: John Peacock <jpea...@rowman.com>
Date: Tue, 06 Apr 2004 21:56:19 -0400
Message-ID: <40735FC3...@rowman.com>
David Dyck
On Thu, 8 Apr 2004 at 17:55 -0700, David Dyck <david...@fluke.com> wrote:
> dd:dcd$ perl -le '$VERSION=1; print main->VERSION'
> 1
> dd:dcd$ perl -le 'print main->VERSION'
> Segmentation fault
This seems to happen in
XS_UNIVERSAL_VERSION (cv=0x814abfc) at universal.c:377
377 ST(0) = vnumify(sv);
(gdb) x sv
0x8140334 <PL_sv_undef>: 0x00000000
when sv is undef
David Dyck
--- universal.c- Wed Apr 7 01:21:37 2004
+++ universal.c Thu Apr 8 18:31:28 2004
@@ -374,7 +374,11 @@
vnumify(req),vnormal(req),vnumify(sv),vnormal(sv));
}
- ST(0) = vnumify(sv);
+ if (sv == (SV*)&PL_sv_undef) {
+ ST(0) = sv;
+ } else {
+ ST(0) = vnumify(sv);
+ }
XSRETURN(1);
}
Chip Salzenberg
pondering something like !SvOK(), but allowing for magic.
According to David Dyck:
> --- universal.c- Wed Apr 7 01:21:37 2004
> +++ universal.c Thu Apr 8 18:31:28 2004
> @@ -374,7 +374,11 @@
> vnumify(req),vnormal(req),vnumify(sv),vnormal(sv));
> }
>
> - ST(0) = vnumify(sv);
> + if (sv == (SV*)&PL_sv_undef) {
> + ST(0) = sv;
> + } else {
> + ST(0) = vnumify(sv);
> + }
>
> XSRETURN(1);
> }
>
--
Chip Salzenberg - a.k.a. - <ch...@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
David Dyck
I just chose that code because sv was set to (SV*)&PL_sv_undef
earlier above for the case that causes the error.
perhaps vnumify could have been changed to handle (SV*)&PL_sv_undef)
being passed to it, or the code above in universal.c could have
been rearanged to set ST(0) explicitly to sv (like it was before)
and avoid the vnumify call.
Rafael Garcia-Suarez
> > > dd:dcd$ perl -le 'print main->VERSION'
> > > Segmentation fault
> >
> > This seems to happen in
> > XS_UNIVERSAL_VERSION (cv=0x814abfc) at universal.c:377
> > 377 ST(0) = vnumify(sv);
> > (gdb) x sv
> > 0x8140334 <PL_sv_undef>: 0x00000000
> >
> > when sv is undef
>
>
> --- universal.c- Wed Apr 7 01:21:37 2004
> +++ universal.c Thu Apr 8 18:31:28 2004
Thanks, applied as #22682.
John Peacock
> perhaps vnumify could have been changed to handle (SV*)&PL_sv_undef)
> being passed to it, or the code above in universal.c could have
> been rearanged to set ST(0) explicitly to sv (like it was before)
> and avoid the vnumify call.
The vnumify() call was so that the return from UNIVERSAL::VERSION was the
numified result rather than the version object itself (which was a cause for
complaints). Sorry about that! I wrote vnumify() under the assumption that the
input was a version object (and already cleansed and checked for undef).
I see that Raphael has already applied your patch; I'll add it to the CPAN
version.pm release (or something equivalent) and release soon.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
John Peacock
>
> Thanks, applied as #22682.
Could you apply this one on top of the last one:
Index: universal.c
==================================================================
--- universal.c (revision 8420)
+++ universal.c (local)
@@ -374,10 +374,10 @@
vnumify(req),vnormal(req),vnumify(sv),vnormal(sv));
}
- if (sv == (SV*)&PL_sv_undef) {
- ST(0) = sv;
- } else {
+ if ( sv_derived_from(sv, "version") ) {
ST(0) = vnumify(sv);
+ } else {
+ ST(0) = sv;
}
XSRETURN(1);
The reason being that the only time vnumify() should be called is when we
already know the scalar is already a version object. In point of fact, this
will not core:
./perl -le '$VERSION = 1.0001; print main->VERSION'
but vnumify() should really only be called on version objects.
Thanks
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
David Dyck
Test-Manifest-0.93 from CPAN lists
'ExtUtils::MakeMaker' => '6.03',
as one of its PREREQ_PM
When processings Test-Manifest-0.93's Makefile.PL I get
Warning: prerequisite ExtUtils::MakeMaker 6.03 not found. We have 6.021002.
I see that perl-current's lib/ExtUtils/MakeMaker.pm
$VERSION = '6.21_02';
What needs to be updated to avoid this warning?
Is ExtUtils::MakeMaker having trouble decoding its own version number?
or
Sould Test::Manifest have endered a different flavor of version number?
I don't remember getting this warning before, as Test::Manifest has
been around since 12/2002.
Notice how
perl -le 'use ExtUtils::MakeMaker; print $ExtUtils::MakeMaker::VERSION;
prints
6.21_02
but
perl -le 'use ExtUtils::MakeMaker; print ExtUtils::MakeMaker->VERSION'
using the UNIVERSAL::VERSION method numifies the version to
6.021002
David
John Peacock
>
> Test-Manifest-0.93 from CPAN lists
> 'ExtUtils::MakeMaker' => '6.03',
> as one of its PREREQ_PM
>
> When processings Test-Manifest-0.93's Makefile.PL I get
> Warning: prerequisite ExtUtils::MakeMaker 6.03 not found. We have 6.021002.
>
> I see that perl-current's lib/ExtUtils/MakeMaker.pm
> $VERSION = '6.21_02';
ARGH! Alpha versions in the core! I know why it's there, but I would much
rather than any dual-lived module exist in the core only in released versions.
The short answer is that the alpha version code parses the underscore as if it
were a special form of the general multi-decimal form (1.2.3). I'll take a look
at it and see if I can make it parse more like a floating point value, since
that is more like what people are expecting here (i.e. it should have been
interpreted as 6.210_02).
FWIW, if EU::MM said this:
$VERSION = '6.210_02';
it would DWIM.
> Notice how
> perl -le 'use ExtUtils::MakeMaker; print $ExtUtils::MakeMaker::VERSION;
> prints
> 6.21_02
That is printing the stringified representation of the version object.
>
> but
> perl -le 'use ExtUtils::MakeMaker; print ExtUtils::MakeMaker->VERSION'
> using the UNIVERSAL::VERSION method numifies the version to
> 6.021002
That is printing the numified representation (since that is what everyone
expected UNIVERSAL::VERSION to return).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
John Peacock
> The short answer is that the alpha version code parses the underscore as
> if it were a special form of the general multi-decimal form (1.2.3).
> I'll take a look at it and see if I can make it parse more like a
> floating point value, since that is more like what people are expecting
> here (i.e. it should have been interpreted as 6.210_02).
No matter which way I change this, someone is going to be unhappy. However,
failing the comparison test has to take precedence over possibly confusing
output. If people had just used three decimal places in the first place, we
wouldn't be in this mess...
OK, here's my proposal (and I have a diff to implement it). The Stored column
shows the internal array representation, so you can see how they will sort:
Init Stored Printed
1.10 [1,100] 1.100
1.11 [1,110] 1.110
1.12 [1,120] 1.120
1.12_01 [1,120,10] 1.120_10
1.13 [1,130] 1.130
Obviously, treating the final column as a number in Perl will mean that the
trailing zeros will vanish, except in the case of the fourth value, where the
implementation details intrude.
Is that a reasonable compromise?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
Stas Bekman
> John Peacock wrote:
>
>> The short answer is that the alpha version code parses the underscore
>> as if it were a special form of the general multi-decimal form
>> (1.2.3). I'll take a look at it and see if I can make it parse more
>> like a floating point value, since that is more like what people are
>> expecting here (i.e. it should have been interpreted as 6.210_02).
>
>
> No matter which way I change this, someone is going to be unhappy.
> However, failing the comparison test has to take precedence over
> possibly confusing output. If people had just used three decimal places
> in the first place, we wouldn't be in this mess...
>
> OK, here's my proposal (and I have a diff to implement it). The Stored
> column shows the internal array representation, so you can see how they
> will sort:
>
> Init Stored Printed
> 1.10 [1,100] 1.100
> 1.11 [1,110] 1.110
> 1.12 [1,120] 1.120
> 1.12_01 [1,120,10] 1.120_10
> 1.13 [1,130] 1.130
>
> Obviously, treating the final column as a number in Perl will mean that
> the trailing zeros will vanish, except in the case of the fourth value,
> where the implementation details intrude.
>
> Is that a reasonable compromise?
Aren't we going back to the problem of:
Init Stored Printed
1.09 [1,90] 1.90
which several agreed that's confusing.
What about the sequence: 1.8, 1.9, 1.10, 1.11
Please make this table including single, double and triple digit examples
after the period. So we don't need to guess.
Thanks, John.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:st...@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
John Peacock
> Aren't we going back to the problem of:
>
> Init Stored Printed
> 1.09 [1,90] 1.90
>
> which several agreed that's confusing.
No, the subsequent terms (except the first) are always printed with %03d, so
that would be:
Init Stored Printed
1.09 [1,90] 1.090
The only thing I am changing is that the trailing zeros will now print out
explicitely (unless it's used in a numeric context). The implementation details
is that the $VERSION->numify() operator (and hence main->VERSION) returns a PV,
not an NV, which the larger context of the code can freely convert to a number.
The result is that it will look basically the same in all cases except for
alpha versions, where the internal representation will be displayed explicitely.
>
> What about the sequence: 1.8, 1.9, 1.10, 1.11
That has _never_ been a legitimate version sequence, since until my code,
$VERSION was a floating point number (and 1.9 > 1.10 ;).
David Dyck
> > What about the sequence: 1.8, 1.9, 1.10, 1.11
>
> That has _never_ been a legitimate version sequence, since until my code,
> $VERSION was a floating point number (and 1.9 > 1.10 ;).
I'll just add some documentation to agree with John here.
The above sequence might have come with RCS/CVS version numbering, and perlmod
instructs the user to transform that into a version by
# if using RCS/CVS, this may be preferred
$VERSION = sprintf "%d.%03d", q$Revision: 1.1 $ =~ /(\d+)/g;
Stas Bekman
> Stas Bekman wrote:
>
>> Aren't we going back to the problem of:
>>
>> Init Stored Printed
>> 1.09 [1,90] 1.90
>>
>> which several agreed that's confusing.
>
>
> No, the subsequent terms (except the first) are always printed with
> %03d, so that would be:
>
> Init Stored Printed
> 1.09 [1,90] 1.090
I guess it's fine then.
> The only thing I am changing is that the trailing zeros will now print
> out explicitely (unless it's used in a numeric context). The
> implementation details is that the $VERSION->numify() operator (and
> hence main->VERSION) returns a PV, not an NV, which the larger context
> of the code can freely convert to a number. The result is that it will
> look basically the same in all cases except for alpha versions, where
> the internal representation will be displayed explicitely.
>
>>
>> What about the sequence: 1.8, 1.9, 1.10, 1.11
>
>
> That has _never_ been a legitimate version sequence, since until my
> code, $VERSION was a floating point number (and 1.9 > 1.10 ;).
Got it. Again, version's manpage is probably a good place to repeat that to
avoid confusion.