Description of problem: The function report_tags in the Perl module HTML::Parser does not give the right result when using the current perl-HTML-Parser-3.26-18.i386.rpm package which apparantly was compiled against an earlier version of Perl. (Among other things, this causes the Perl function, HTML::Form->Parse to fail). It appears that the problem is due to a binary incompatibility between Perl 5.8.0 and 5.8.1 caused by the introduction of hash randomization in Perl 5.8.1. (Note that the report_tags function is defined as an HV*). The solution is to simply rebuild the src rpm under Fedora Core 1/Perl 5.8.1. I am not sure if this binary incompatibility between Perl 5.8.0 and 5.8.1 affects any other Perl modules, but it might be a good idea to check this out and see whether any of the other Perl packages need to be rebuilt for Fedora Core 1. Version-Release number of selected component (if applicable): perl-HTML-Parser-3.26-18 How reproducible: Steps to Reproduce: To reproduce, try the following short perl script: #! /usr/bin/perl -w use HTML::Form; use HTTP::Request; use LWP; use Data::Dumper; my $ua = LWP::UserAgent->new; my $uri="http://www.google.com"; my $req = HTTP::Request->new(GET => $uri); my $res = $ua->request($req); my $form = HTML::Form->parse($res->content, $res->base()); print Dumper($form); Actual results: When run under FC1/Perl 5.8.1 without a rebuild, the script does not 'dump' the form and instead returns: $VAR1 = undef; Expected results: The above script prints out the form properly in RH8.0/Perl 5.8.0 (and in FC1/Perl 5.8.1 after rebuild): $VAR1 = bless( { 'extra_attr' => { 'name' => 'f' }, 'enctype' => 'application/x-www-form-urlencoded', 'action' => bless( do{\(my $o = 'http://www.google.co +m/search')}, 'URI::http' ), 'method' => 'GET', 'inputs' => [ bless( { 'value' => 'en', 'name' => 'hl', 'type' => 'hidden' }, 'HTML::Form::TextInput' ), bless( { 'value' => 'ISO-8859-1', 'name' => 'ie', 'type' => 'hidden' }, 'HTML::Form::TextInput' ), bless( { 'maxlength' => '256', 'value' => '', 'name' => 'q', 'type' => 'text', 'size' => '55' }, 'HTML::Form::TextInput' ), bless( { 'value' => 'Google Search', 'name' => 'btnG', 'type' => 'submit' }, 'HTML::Form::SubmitInput' ), bless( { 'value' => 'I\'m Feeling Lucky +', 'name' => 'btnI', 'type' => 'submit' }, 'HTML::Form::SubmitInput' ) ] }, 'HTML::Form' ); Additional info: None
This bug definitely caused troubles for spamassassin also... I had thought that my issues reported with bug 90202 was being caused by perl or spamassassin itself but it was not. After reading this bug I did rebuild perl-HTML-Parser-3.26-18.x86_64.rpm and after installing it I rebuilt spamassassin-2.61-2.x86_64.rpm and installed it as well. Suddenly all is well in spamassassin land!
Not sure why this bug has not yet been addressed by the Fedora bug team. It has got to be one of the easiest of bugs to fix -- just recompile the module rpm and re-release. This bug is probably tripping up many people who don't realize it, since it is not exactly easy to find or troubleshoot. Maybe I should change the priority soon if no response from the official maintainers :) Jeff
Is this still an issue with FC1 + official updates?
YES!!! Extremely frustrating that not responded to or corrected yet,particularly given that the fix is specified and is SO simple (just rebild the darn rpm) Response like this has to make you wonder about how well the community Fedora Core is being managed and maintained relative to the for-profit Redhat project. I mean, how many months does it take to respond to a simple bugzilla report? (it has been two months so far...)
*** Bug 113891 has been marked as a duplicate of this bug. ***
I think I have figured out why this has not attracted attention. 1) This seems to crash only FC1 AMD64 and not x86. 2) This report did not mention x86-64 or AMD64 anywhere. 3) Other folks probably saw this report and tested it quickly on x86 where it does not seem to crash. When they were unable to quickly reproduce it, so it went to the bottom of the pile in priority. 4) I do not recall you saying anything about this to the mailing list, and Justin Forbes the AMD64 guy did not hear anything from you. So I am guessing that it was only a failure of communication. There are core bugfix updates going into FC1 real soon, so this should be fixed relatively quickly.
I have a Intel P4. Not sure why others haven't been able to duplicate on x86, but problem is a 100% duplicable for me (by comparing original vs rebuilt rpm). I also know problem is 'genuine' since this same binary incompatibility between Perl 5.8.0 and 5.8.1 is noted on the main Perl sites. However, since issue is related to hash randomization, I could imagine that by luck some states still work while others don't. Finally, even if others had tried and not verified the bug, shouldn't they have noted that here in bugzilla? Again, my frustration is that I didn't hear *any* responses for 2 months. Thanks :)
This bug seems to effect perl-DBI-1.37-1 as well. Things like sqlbench are unable to run due to perl-DBI being built against an older perl.
I should mention that perl-DBI seems effected on x86_64, not i386.
perl-DBD-MySQL as well, and I would assume perl-DBD-Pg.
Have you tried the latest perl errata (5.8.3)? Check 'man perl582delta' -- the binary incompatibility was fixed. can you see if the 5.8.3 errata fixes your situation? or are you already running it?
Yes, this is still a problem because I CANNOT install the updated perl on x86_64 ... why not, see bugzilla 117646
http://people.redhat.com/wtogami/temp/perl-5.8.3-16.i386.rpm http://people.redhat.com/wtogami/temp/perl-5.8.3-16.x86_64.rpm Please test the appropriate version of perl for your system. This should be binary compatible with the ORIGINAL perl-HTML-Parser package distributed in FC1.
*** This bug has been marked as a duplicate of 117646 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.