Bug #81420 for Class-AutoClass: Test failures due to hash randomisation in perl 5.17.6

Sat Nov 24 18:10:52 2012 ANDK [...] cpan.org - Ticket created

Subject:

Test failures due to hash randomisation in perl 5.17.6

Since bleadperl v5.17.5-518-g7dc8663 tests are failing frequently. That commit introduced hash key randomization and it seems at least the tests t/autoclass.011.inconsistent.t and t/autoclass.101.no_use_parent.t sometimes misbehave under hash randomization Sample fail report: http://www.cpantesters.org/cpan/report/b608a0ae-3295-11e2-9d79-7ca1a290f8f5 HTH && Thanks && Regards,

Sat Nov 24 19:44:19 2012 NATG [...] cpan.org - Correspondence added

Hello Andreas- Thanks for the bug report. I took a look and it's not obvious how hash key randomization could be breaking this code. I must admit that I thought hash key randomization was introduced in 5.8, but as I searched the web to learn more about how it might be affecting my code, I came across a discussion group posting indicating that it was reverted soon thereafter, at least in most cases. Can you point me to a description of what exactly perl means by "hash key randomization" at this point in time? Is there a way to disable it, as there was in 5.8 or thereabouts? I don't have access to a machine running perl 5.17.5, which will make it challenging for me to track down such a subtle bug. I appreciate any advice you can offer on how I might attack the problem. Many thanks and best wishes for the holiday season, Nat Goodman On Sat Nov 24 18:10:52 2012, ANDK wrote: Show quoted text

> Since bleadperl v5.17.5-518-g7dc8663 tests are failing frequently. That > commit introduced hash key randomization and it seems at least the tests > t/autoclass.011.inconsistent.t and t/autoclass.101.no_use_parent.t > sometimes misbehave under hash randomization > > Sample fail report: > > http://www.cpantesters.org/cpan/report/b608a0ae-3295-11e2-9d79-7ca1a290f8f5 > > HTH && Thanks && Regards,

Sat Nov 24 19:44:20 2012 The RT System itself - Status changed from 'new' to 'open'

Sun Nov 25 04:51:26 2012 ANDK [...] cpan.org - Correspondence added

http://perl5.git.perl.org/perl.git/commit/7dc8663964c66a698d31bbdc8e8abed69bddeec3 This is the quite verbose commit message accompanying the single most important commit about the new hash randomization. I think it answers some of your questions. In any case, I personally don't know more about it anyway. When I look at the report I had linked to, I see # Attribute b: declared instance attribute in autoclass_011::Inconsistent2, class attribute in autoclass_011::Inconsistent1 # Attribute a: declared instance attribute in autoclass_011::Inconsistent1, class attribute in autoclass_011::Inconsistent2 at /tmp/loop_over_bdir-sVjhsS/Class-AutoClass-1.54-UrlHHT/blib/lib/Class/AutoClass.pm line 605. You see the order of Inconsistent{1,2} is flipped somehow. Another obesrvation I see in my smoker is that you're depending on Hash-AutoHash-Args and possibly the hash order dependency is stemming from there?

Sun Nov 25 09:32:01 2012 NATG [...] cpan.org - Correspondence added

Thanks for your persistence. With the benefit of your insight about the "order of Inconsistent{1,2}", a night's sleep, and a strong cup of coffee, I see that you are completely right. Both errors result from assumptions in my code about the order of hash keys. I wonder how many more there are... I'll cut a new version (1.55) with these bugs fixed and see what breaks next. Thanks also for sending the link. Best, Nat On Sun Nov 25 04:51:26 2012, ANDK wrote: Show quoted text

> http://perl5.git.perl.org/perl.git/commit/7dc8663964c66a698d31bbdc8e8abed69bddeec3 > > This is the quite verbose commit message accompanying the single most > important commit about the new hash randomization. I think it answers > some of your questions. In any case, I personally don't know more > about > it anyway. > > When I look at the report I had linked to, I see > > # Attribute b: declared instance attribute in > autoclass_011::Inconsistent2, class attribute in > autoclass_011::Inconsistent1 > # Attribute a: declared instance attribute in > autoclass_011::Inconsistent1, class attribute in > autoclass_011::Inconsistent2 at > /tmp/loop_over_bdir-sVjhsS/Class-AutoClass-1.54- > UrlHHT/blib/lib/Class/AutoClass.pm > line 605. > > You see the order of Inconsistent{1,2} is flipped somehow. > > Another obesrvation I see in my smoker is that you're depending on > Hash-AutoHash-Args and possibly the hash order dependency is stemming > from there?

Sun Nov 25 15:53:37 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Sun Nov 25 04:51:26 2012, ANDK wrote: Show quoted text

> http://perl5.git.perl.org/perl.git/commit/7dc8663964c66a698d31bbdc8e8abed69bddeec3 > > This is the quite verbose commit message

The short version is: A security feature (rehash) to prevent DoS attacks slows down all hash access. Replacing that with randomisation instead speeds things up.

Sun Nov 25 16:21:50 2012 NATG [...] cpan.org - Correspondence added

Thanks for the clarification. I understand the rationale for hash randomization, just wanted to see more of the technical details. Seems like considerable overkill for the many perl applications, like mine, that have a tiny user base and aren't likely to experience DoS attacks. Why not a 'use secure' pragma or something that turns on a whole slew of security features that applications like mine can safely ignore? Thanks, Nat On Sun Nov 25 15:53:37 2012, SPROUT wrote: Show quoted text

> On Sun Nov 25 04:51:26 2012, ANDK wrote:

> >

> http://perl5.git.perl.org/perl.git/commit/7dc8663964c66a698d31bbdc8e8abed69bddeec3

> > > > This is the quite verbose commit message

> > The short version is: A security feature (rehash) to prevent DoS > attacks slows down all hash > access. Replacing that with randomisation instead speeds things up.

Sun Nov 25 16:39:39 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Sun Nov 25 16:21:50 2012, NATG wrote: Show quoted text

> Thanks for the clarification. I understand the rationale for hash > randomization, just wanted to > see more of the technical details. > > Seems like considerable overkill for the many perl applications, like > mine, that have a tiny user > base and aren't likely to experience DoS attacks. Why not a 'use > secure' pragma or something > that turns on a whole slew of security features that applications like > mine can safely ignore?

That would not solve the other half I didn’t mention: Perl has switched to a new hashing algorithm as well, faster than before, so the order of keys is changing anyway.