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 $/; };
my @xpath = qw(
/p:pips/p:version/p:segment_events/p:segment_event[@pid="p0000004"]/p:ids/p:id
/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!';
}
__DATA__
# 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 London.pm 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.
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.
Re:Context?
Ovid on 2008-12-23T13:41:19
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.
Re:hash order issue?
Ovid on 2008-12-23T21:00:02
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.