Slash Boxes
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 ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Tuesday December 23, 2008
06:30 AM

Perl Hell

[ #38138 ]

Here's what has me stumped today:

#!/usr/bin/env perl

use strict;
use warnings;

use Test::Most 'no_plan';
use Test::XML::XPath;

my $xml = do { local $/; <DATA> };

my @xpath = qw(
    /p:pips/p:version/p:segment_events/p:segment_event[@pid="p0000004"]/p:ids/p:id[1 ]
    /p:pips/p:version/p:segment_events/p:segment_event[@pid="p0000004"]/p:ids/p:id[2 ]
    not(/p:pips/p:version/p:segment_events/p:segment_event[@pid="p0000004"]/p:ids/p: id[3])
    count(/p:pips/p:version/p:segment_events/p:segment_event[@pid="p0000004"]/p:ids/ p:id)=2

for my $xpath (@xpath) {
    like_xpath $xml, $xpath, 'whee!';
# our XML

Know what it takes to get that to pass? This:

for my $xpath (@xpath) {
    my $anything = undef;
    like_xpath $xml, $xpath, 'whee!';

Or this:

for my $xpath (@xpath) {
    like_xpath $xml, $xpath, 'whee!';
ok 1;

Trying to reduce that to a minimal test case for a bug report has failed miserably. It appears that any sort of assignment anywhere in the like_xpath code will cause these tests to pass and the mere act of moving the affected files to other directories also appears to make tests pass. Running these tests under the debugger also makes them pass. Printing out any affected variables makes these tests pass. Hell, I suspect that breathing heavy would make these tests pass.

This is Perl 5.8.8 on Solaris. Earlier this month, Andy Wardley started a thread about this version of Perl segfaulting due to a comment. Some people could reproduce his error and others couldn't. Versions of Perl other than 5.8.8 seemed fine (and not all 5.8.8 seemed affected). I'm beginning to suspect that 5.8.8 has a parser issue. Since Perl's parsing is heuristic-based, this is a bugger (ha!) to track down.

Update: Pardon me, but F****************K! As mentioned, any assignment of a variable in the like_xpath code will fix this bug -- but only for my minimal test case. One of our actual tests still fails roughly 1 out of 5 runs. The XML returned is always the same, aside from timestamps which aren't in the xpath. I'm going insane.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Have you checked the context that the like_xpath() call is invoked in? It looks to me like it should be in void context, and probably, it isn't.

    This often bites me with Data::Dump::Streamer, where Dump() needs to be in void context to print anything. And a bare Dump statement, more often than not, is in scalar or list context.

    Argh! I wish Perl required explicit return (as in Javascript) to return values, so context of statements would always be void unless explicitly overridden.

    • The context in which it's called doesn't matter. I'm reading the code now and it shouldn't make any difference. Of course, sometimes just adding a comment to the like_xpath code causes these tests to pass, but only in the example above. In the actual test, it still fails about 1 out of 5 runs.

      Well, that's not quite true. It now fails about 1 out of 8 runs after a fresh checkout. However, the failure above stopped failing as soon as I checked it in to source control and checked it back out again.

  • my ignorant guess is hash key ordering.
    • I wondered about that myself as I had just worked on a Catalyst bug involving that (one that's fixed in the current version), but the my $anything = undef; line seems to eliminate that thought. Plus, the fact that my small test case which always failed passes if I commit it to Subversion and check the branch again :(

      I've heard anecdotal stories of possible parsing issues in 5.8.8, but I don't see them reported as bugs, so it's tough to say if this is true or if it's related to my problem.

  • Are you able to run it under valgrind or something equivalent?