Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of markjugg (792)

Friday October 03, 2008
09:08 AM

Dear Lazyweb: Help me solve a hard bug in a popular module

[ #37596 ]

At some point a CGI::Application::Plugin::ValidateRM test started failing, and I'm having a heck of time figuring out why.

I'm fairly sure something in the dependency chain changed behavior, and I've been unable to track down what the real issue is.

Take a look at the bug report and the test reports.

I'll be in Portland, OR next week (and will possibly attend the PDX PM meeting), and hopefully Lazyweb will have an answer for me about this when I get back.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Just a wild guess, based on my own experiences with surprise failures recently and a quick skim of the bug reports you linked to:

    Back in July, Gisle Aas changed HTTP::Message (the superclass of HTTP::Response) to do additional Unicode validation and downgrading. Previously that module just assumed content was bytes rather than characters. This change broke Test::WWW::Mechanize::Catalyst in particular, because that module had a workaround for a WWW::Mechanize unicode bug, but the HTTP::Message change kille

  • Mark,

    I looked deeper and I believe the cause is so obvious that you just overlooked it. The only reason ANYONE got test passes in 2.1 is because of the SKIP. The test is just broken. There's no way that "HUH" can be stripped off the output, so there's no way the test can ever pass if it is actually run.

    An example passing test from 2.1 says:

    t/forward.....ok
            2/4 skipped: various reasons

    • Chris,

      Thanks so much! I think you are right.

      Perhaps something changed in the standard way that CPAN testers sets up and run smoke tests. It used to be that sometimes tests succeeded-- perhaps because they were being skipped, but now they consistently aren't.

      I'll plan to update the test and make a new release.

                Mark

    • As I went back to this, I found another part of the mystery. My development environment was FreeBSD 6.1 with Perl 5.8.0.

      There, my testing results for this issue were inverted. The code that fails everywhere else passes for me, and code that should pass, fails.

      I made a branch on a Ubuntu 8.04 Linux laptop, and got results consistent with the rest of the world.

      I'm not sure I'll ever fully understand what was going on here, but it's certainly another indicator it's time to get that Perl upgraded!