# New Ticket Created by Andy Dougherty
# Please include the string: [perl #39197]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39197 >
Currently, many of the imcc tests are failing with core dumps, but
lib/Parrot/Test.pm ignores such failures, so testers may not have noticed
them.
Here's what happens. Consider test t/compilers/imcc/imcpasm/cfg.t. The
first test runs
./parrot --output=t/compilers/imcc/imcpasm/cfg_1.pasm \
t/compilers/imcc/imcpasm/cfg_1.pir
On Linux/x86, that test successfully writes the output file, but then
receives a Segmentation Violation and dumps core as
packfile.c:do_sub_pragmas attempts to dereference 'self', which is NULL.
However, lib/Parrot/Test.pm ignores this. Here's how it runs the test (in
sub run_command):
system( $_ ) for (@{$command});
my $exit_code = $? >> 8;
Note that it throws away the lower-order 8 bits without even checking
them to be sure they are 0. In this case, the exit_code is 139
(Signal 11, plus 128 indicating a core dump. Again, these exact numbers
are, of course, platform-dependent.)
Odder still, changing it to something like this:
my $exit_code = ($? & 127) ? $? : $? >> 8;
doesn't help, since run_command is called from functions generated by
sub _generate_functions, which deal with the exit code like this:
$builder->diag("'$cmd' failed with exit code $exit_code")
if $exit_code and not $pass;
Since the output file was successfully built, $pass is true, and this
diagnostic never gets called.
Deleting the 'and not $pass' part doesn't really help either, since this
is only a diagnostic message. t/harness will still regard the test as
'ok' even though it dumps core.
I guess I just don't understand why the exit status gets ignored in this
way.
--
Andy Dougherty [EMAIL PROTECTED]
