Bleadperl v5.19.3-16-gce0d59f breaks the CPAN #13193
Comments
From @andkgit bisect ce0d59f is the first bad commit [perl #7508] Use NULL for nonexistent array elems affected This is only a first impression. Dependencies of all of these are not yet MIYAGAWA/CGI-Compile-0.16.tar.gz perl -V Summary of my perl5 (revision 5 version 19 subversion 4) configuration: Characteristics of this binary (from libperl): -- |
From @andkAlso affected: MDOOTSON/Wx-0.9922.tar.gz -- |
From @bingosOn Thu, Aug 22, 2013 at 02:29:10PM -0700, Andreas J. Koenig via RT wrote:
Regarding BINGOS/POE-Component-Client-Ident-1.16.tar.gz, I built a bleadperl and tested this. A SEGV was being thrown during the tests. The fault happens here: During the test the fifth element returned is an undef. Adding $returns[5] = 0 unless defined $returns[5]; to _parse_arguments() eliminates the SEGV. --
|
|
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Thu Aug 22 14:29:10 2013, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
Commit 428ccf1 probably fixes many of these. -- Father Chrysostomos |
From @cpansproutOn Sun Aug 25 12:16:09 2013, sprout wrote:
Fixed by 428ccf1: ADAMK/List-MoreUtils-0.33.tar.gz Still broken: ZEFRAM/Data-Alias-1.17.tar.gz I cannot test these: XAOC/Gtk2-1.247.tar.gz -- Father Chrysostomos |
From @bulk88On Sun Aug 25 12:57:03 2013, sprout wrote:
About commit 428ccf1 I'm not very awake right now so this might be a stupid question, what is -- |
From @cpansproutOn Sun Aug 25 13:33:58 2013, bulk88 wrote:
Most pp functions actually don’t know how to handle them and have always
Actually subs in the CORE:: namespace use them to indicate missing -- Father Chrysostomos |
From @bulk88On Sun Aug 25 14:56:00 2013, sprout wrote:
Any point of teaching them how to handle NULL SV *s? For exaple "#define
-- |
From @cpansproutOn Sun Aug 25 19:29:25 2013, bulk88 wrote:
I don’t think it would be worth it. -- Father Chrysostomos |
From @andk"Father Chrysostomos via RT" <perlbug-followup@perl.org> writes:
On a closer look I have to add another one: XAOC/Glib-1.301.tar.gz All three still broken here. Glib sample fail: http://www.cpantesters.org/cpan/report/66f63634-0aa3-11e3-b8e0-d7a45735fcd0 -- |
From @andkAlso affected and still broken: MSTROUT/YAML-0.84.tar.gz -- |
From @cpansproutZEFRAM/Data-Alias-1.17.tar.gz - patch at rt.cpan.org #88176 a600f7e fixes: GAAS/Data-Dump-1.22.tar.gz Still broken: ANDYA/Data-Structure-Util-0.15.tar.gz -- Father Chrysostomos |
From @andkAlso affected and still broken but only with threaded perls: DOY/Try-0.03.tar.gz Failing with: % /home/src/perl/.../bin/perl Makefile.PL -- |
From @cpansproutPatched: ZEFRAM/Data-Alias-1.17.tar.gz - rt.cpan.org #88176 Fixed: GGOEBEL/Class-Contract-1.14.tar.gz by perl commit 3df5c4b GGOEBEL/Class-Contract-1.14.tar.gz’s tests pass, but still emit warnings Broken: BDARRAH/Proc-ParallelLoop-0.5.tgz Presumably broken still: XAOC/Gtk2-1.247.tar.gz -- Father Chrysostomos |
From @cpansproutOn Fri Aug 30 01:26:28 2013, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
Fixed in 7601007, though it is still subtly broken in 5.18. See -- Father Chrysostomos |
From @cpansproutOn Sun Sep 01 18:35:05 2013, sprout wrote:
Unrelated. It seems different versions of ExtUtils::Command::MM may or -- Father Chrysostomos |
From @cpansproutOn Sun Sep 01 18:35:05 2013, sprout wrote:
Correction: IPC::Pipeline passed its tests for me, since .cpan/build -- Father Chrysostomos |
From @cpansproutOn Wed Aug 28 02:42:57 2013, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
Fixed in 4981938. *That* was a hard one to track down! Only the three distributions by XAOC remain. -- Father Chrysostomos |
From @cpansproutOn Mon Aug 26 03:23:27 2013, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
I have committed various fixes to blead. Could you test them again?
http://www.cpantesters.org/cpan/report/66f63634-0aa3-11e3-b8e0-d7a45735fcd0 Every time I try to use cpantesters, the site is down. Could you give me some sample failure output? -- Father Chrysostomos |
From @andk"Father Chrysostomos via RT" <perlbug-followup@perl.org> writes:
Both Gtk2 and Pango depend on Glib. Glib compilation and test run attached. -- |
From @cpansproutOn Sun Sep 08 00:27:36 2013, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
Thank you. And what is the output with the attached patch? -- Father Chrysostomos |
From @cpansproutInline Patchdiff -rup Glib-1.301-gy1yG6/GType.xs Glib-1.301-8jML2z/GType.xs
--- Glib-1.301-gy1yG6/GType.xs 2013-06-23 09:55:30.000000000 -0700
+++ Glib-1.301-8jML2z/GType.xs 2013-09-08 11:20:19.000000000 -0700
@@ -1106,6 +1106,7 @@ gperl_real_signal_accumulator (GSignalIn
"### this is really uncool, and for now i'm not even going to\n"
"### try to recover.\n"
"### aborting");
+ warn("### The error is %"SVf, ERRSV);
abort ();
}
|
From @andk"Father Chrysostomos via RT" <perlbug-followup@perl.org> writes:
PERL_DL_NONLAZY=1 /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.3-374-ga8162dc/9980/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/7.t -- |
From @cpansproutOn Sun Sep 08 13:45:54 2013, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
What about with the attached? -- Father Chrysostomos |
From @cpansproutInline Patchdiff -rup Glib-1.301-gy1yG6/GType.xs Glib-1.301-8jML2z/GType.xs
--- Glib-1.301-gy1yG6/GType.xs 2013-06-23 09:55:30.000000000 -0700
+++ Glib-1.301-8jML2z/GType.xs 2013-09-08 16:25:48.000000000 -0700
@@ -1091,7 +1091,10 @@ gperl_real_signal_accumulator (GSignalIn
PUSHMARK (SP);
PUSHs (sv_2mortal (newSVGSignalInvocationHint (ihint)));
- SAVED_STACK_PUSHs (sv_2mortal (gperl_sv_from_value (return_accu)));
+ sv = gperl_sv_from_value (return_accu);
+ if (sv == &PL_sv_undef)
+ sv = newSV (0);
+ SAVED_STACK_PUSHs (sv_2mortal (sv));
SAVED_STACK_PUSHs (sv_2mortal (gperl_sv_from_value (handler_return)));
if (callback->data) |
From @andk"Father Chrysostomos via RT" <perlbug-followup@perl.org> writes:
Excellent, all tests pass, also for Pango and Gtk2. -- |
From @cpansproutOn Sun Sep 08 22:21:12 2013, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
Thank you for being so patient! I have submitted the patch to rt.cpan.org #88533. I have listed the patched modules in perl5200delta, so I can close this -- Father Chrysostomos |
|
@cpansprout - Status changed from 'open' to 'resolved' |
From @rjbsRe-opened. -- |
|
@rjbs - Status changed from 'resolved' to 'open' |
From @iabynOn Sat, May 10, 2014 at 10:27:22AM +0200, Andreas Koenig wrote:
Coro directly accesses the AvARRAY of an object. Since slf_init_rw (pTHX_ struct CoroSLF *frame, SV *arg, int wr) now SEGVs. Presumably Marc either needs to use the official API, i.e. av_fetch(), -- |
From schmorp@schmorp.deOn Mon, May 12, 2014 at 03:55:53PM +0100, Dave Mitchell <davem@iabyn.com> wrote:
Thanks for the info and the analysis, to both of you (I didn't have time
Since the array in question is internal to Coro, it'll probably just need A minor nitpick though: there really isn't such a thing as an official API -- |
From @demerphqOn 12 May 2014 16:55, Dave Mitchell <davem@iabyn.com> wrote:
Is there a reason for this change? Ironically yesterday I encountered this Yves -- |
From @LeontOn Mon, May 12, 2014 at 5:27 PM, Marc Lehmann <schmorp@schmorp.de> wrote:
AvARRAY is not documented in perlapi. The only things that are documented On the other hand, perlguts does document that «AVs use &PL_sv_undef as a The real issue is very different. Almost any non-trivial XS module is Leon |
From @demerphqOn 12 May 2014 22:37, Leon Timmermans <fawaka@gmail.com> wrote:
Its mentioned there under the sort method.
No we dont tend to guarantee stuff like this.
What do you mean "this is incorrect"? The regression I am pointing out here And actually I guess I answer my own question about why: commit ce0d59f [perl #7508] Use NULL for nonexistent array elems This commit fixes bug #7508 and provides the groundwork for fixing Elements of @_ are aliased to the arguments, so that \$_[0] within &PL_sv_undef (the global read-only undef scalar returned by the This also causes other problems with constants under ithreads This commit changes the internals to use a null pointer to represent a This requires that Storable be changed to account for it. Also, But I consider this an XS regression. I dont much care, I will just work
Im now confused what "this" is in the above sentence.
I agree that we should harden some of these apis. Yves -- |
From @LeontOn Tue, May 13, 2014 at 3:28 AM, demerphq <demerphq@gmail.com> wrote:
Mentioned != documented On the other hand, perlguts does document that «AVs use &PL_sv_undef as a
I meant "the documentation no longer matches reality".
I think that's reasonable.
this = ce0d59f Leon |
From schmorp@schmorp.deOn Mon, May 12, 2014 at 10:37:58PM +0200, Leon Timmermans <fawaka@gmail.com> wrote:
And neither mentions anything "official". Since it's not a defined term
I don't understand why there are volunteers who gratituiously break Yes, I am sure those are easier to find than the other variety, but in my I don't agree with your assessment that volunteers are needed. In my Also, the atmosphere on p5p makes it very hard to volunteer. The very few Some fixes are trivial, but impossible to apply - I lobbied for years to So, to me, the problem is (some - I am absolutely convinced that there I am certainly not the only one who is concerned with the dichotomy of -- |
From @demerphqOn 15 May 2014 13:19, Marc Lehmann <schmorp@schmorp.de> wrote:
FWIW, I think taking the position that AvARRAY() is not documented or So for instance with regard to AvARRAY() IMO it was wrong to change the I think we *have* to get better about this subject. And I think you have
I think *most* of our developers do not *gratuitously* break back-compat.
This I definitely dont agree with. We do not have enough good devs willing
I agree with you here. There are certain people on p5p who have never ever
I agree with most of that, although not all since your reference to Also, when you got all hysterical about the hash changes you really didn't So lets keep a sense of proportion here. Yes as far as language design we On the other hand, you have a tendency towards hyperbole and hysteria in
If you had a list of things you see as issues I would like to read it. I am I wanted to say one last thing, this mail has been one of the more Yves -- |
From @bulk88On Thu May 15 05:45:36 2014, demerphq wrote:
I think AvARRAY should NOT be public api. It limits what can be done in the future, like linked lists, or unifying hashes and arrays. -- |
From @demerphqOn 16 May 2014 01:22, bulk88 via RT <perlbug-followup@perl.org> wrote:
I dont see us doing anything like that ever (you want to sort linked Yves -- |
From @tseeOn 05/16/2014 07:58 AM, demerphq wrote:
IMO it would be a fine example of the kind of API that we acknowledge --Steffen [1] In theory, I'm sure somebody can point out a case where that failed. |
From @LeontOn Fri, May 16, 2014 at 7:58 AM, demerphq <demerphq@gmail.com> wrote:
If we want to be able to have array/hash vtables, not exposing Leon |
From @demerphqOn 16 May 2014 12:45, Leon Timmermans <fawaka@gmail.com> wrote:
Shrug, I dont care. Ill make Sereal do whatever. But until then the Array I really think this is one of those cases where by trying to keep our So how do we address these things? Maybe introduce some primitives that are currently no-ops, but later on Maybe something like: SvVTABLE(sv) which would return 0 for now but when we get a vtable implementation will Or how about just documenting that AvARRAY() may return false in some My point is there are lots of ways to make this stuff work without making Yves -- |
From @iabynOn Fri, May 16, 2014 at 07:58:14AM +0200, demerphq wrote:
Any XS code which directly accesses AvARRAY() is already broken with respect How many people on this list could confidently say (without checking the * NULL (I can imagine a lot of XS code happily trying to write to PL_sv_placeholder). I think this is strictly an implementation detail which we should feel -- |
From @bulk88On Thu May 15 16:22:07 2014, bulk88 wrote:
Another provision is, what if AvARRAY isn't a SV**, but an AE *. It means that an AE * is 2 pointer sizes. What the other half is used for IDK, but someone could find a compelling reason. Someone could also say that AvARRAY points to an array of tagged SV* psuedo-pointers. Even though SVs are 16 or 24 bytes long, perl doesn't use the lowest 3 or 4 bits for anything, even though they will always be zero. Maybe someone will think of a use for the lowest 3 or 4 bits in relation to AVs. Maybe for doing random deletes on a each() pass through an AV or HV through some kind of "soft delete" flag or "already visited" flag. -- |
From @demerphqOn 17 May 2014 16:16, Dave Mitchell <davem@iabyn.com> wrote:
That is somewhat of a simplification. Any code that uses AvARRAY() without But this is well known. The exposed perl guts api's all make it clear that
But this is my point. Why should we? Why shouldnt we have a clear macro
I never said we shouldn't. I said that when we do we should provide ways The reality is people use XS for performance. To get performance the IMO failing to recognize and accommodate this just makes everyone unhappy. The alternative is recognize people want to do these things, and that it And the reality is that people do this stuff all the time. Sereal does it, Check this out: $ git grep -l AvARRAY dist ext cpan We even mention AvARRAY() in both perlapi and perlguts: perldoc perlapi: sortsv Sort an array. Here is an example: sortsv(AvARRAY(av), av_len(av)+1, Perl_sv_cmp_locale); Currently this always uses mergesort. See sortsv_flags for a void sortsv(SV** array, size_t num_elts, We mention AvARRAY in perlguts: Something similar to the offset hack is performed on AVs to enable If AvARRAY() is completely opaque to the user why do we have interfaces I hold that if you want to do interesting or useful things with Perl in XS Ultimately I think at some point I think it is important to recognize that So lets change it. Yves |
From @bulk88On Sun May 18 04:48:51 2014, demerphq wrote:
We don't document amagic or how to run overload methods. Tied is barely documented other than the SV * returned from the HV/AV is magical, remember to call setmagic on it the appropriate number of times.
What would the meaning of that macro be? what if more states need to be added than what those 3 represent (IDK what they represent).
Those 2 prepositions conflict. Using undocumented/abstracted means you take the risk if it breaks and it will break and dont expect a decade of source code compatible compiling then. The other choice is do a massive rewrite of the perl headers so PERL_CORE headers are different from XS. Or use a preprocessor at perl build time to delete PERL_CORE defed code. But that would lead to people copy pasting structs. The next choice is to XOR all pointers with a static secret key and SvLEN and SvCUR are function calls (we did something like this http://perl5.git.perl.org/perl.git/commitdiff/87b9e16005b9e39b8a24388159e899fe54b95979 , its crazy inefficient, and I dont want it back). Or Metacpan could put a red triangle with ! in it for .xs and .c code that makes a regex of perintern pod match.
To what? AFAIK from reading p5p history, the concept of "public api" was an afterthought, since originally there was no CPAN and all XS code was included in the Core by Larry. https://groups.google.com/d/msg/perl.perl5.porters/ZpZK8X1D8Ms/LHP06JdA6DkJ We have 3 pools that macros/funcs fall into right now. Always safe. Murky. Unstable. Function calls are usually safe. Macros are murky. struct access is usually unstable. I think MG is the only struct where we have documented access to its members. All the other structs are macroed. -- |
From @iabynOn Sat, May 17, 2014 at 11:47:38AM -0700, bulk88 via RT wrote:
What, in this context, is an AE? -- |
From @LeontOn Tue, May 20, 2014 at 3:35 PM, Dave Mitchell <davem@iabyn.com> wrote:
I presume it's the array equivalent of an HE*. I don't really see the point Leon |
From @bulk88On Tue May 20 10:47:17 2014, LeonT wrote:
Yes, AE="array entry", named after HE. -- |
From m.nooning@comcast.netIf it helps, I used "cpan install AnyEvent" on my Windows XP, with Strawberry Perl 5.20 and with 5.20.1, and got the same results with both Perls, as reported in the now closed ticket 121727. The ticket was closed because it was judged that this current ticket is the real problem. |
From @iabynKarl, I note that you've added this old ticket (about AnyEvent/EV/Coro) If I'm reading it right, this ticket referred to a failing test in Coro So, far from being a 5.22 blocker, this ticket could be closed? -- |
From @khwilliamsonOn 03/26/2015 08:43 AM, Dave Mitchell wrote:
As I told rjbs on irc, at the time I did this, I went through an |
|
@iabyn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#119433 (status was 'resolved')
Searchable as RT119433$
The text was updated successfully, but these errors were encountered: