Ticket #281 (closed bug: fixed)

Opened 13 years ago

Last modified 13 years ago

'make testf' fails on 32bit linux i386 (debuginfo.t)

Reported by: moritz Owned by:
Priority: normal Milestone: 1.3
Component: none Version:
Severity: medium Keywords:
Cc: chromatic, whiteknight Language:
Patch status: Platform:

Description

On 32 bit i386, Debian Etch, 'make testf' fails in debuginfo.t

#   Failed test 'setfile and setline'
#   at t/op/debuginfo.t line 163.
#                   'Could not find non-existent sub no_such_function
# current instr.: 'main' pc 0 (xyz.pir:124)
# '
#     doesn't match '/\(xyz.pir:126\)/
# '
# './parrot -D40 -f --gc-debug  "/home/moritz/rakudo/parrot/t/op/debuginfo_7.pir"' failed with exit code 1

#   Failed test 'setfile and setline'
#   at t/op/debuginfo.t line 176.
#                   'Could not find non-existent sub nsf
# current instr.: 'main' pc 0 (foo.p6:124)
# '
#     doesn't match '/\(foo.p6:128\)/
# '
# './parrot -D40 -f --gc-debug  "/home/moritz/rakudo/parrot/t/op/debuginfo_8.pir"' failed with exit code 1
# Looks like you failed 2 tests of 8.

Attachments

patch.diff Download (326 bytes) - added by rg 13 years ago.
Patch to fix the bug
patch2.diff Download (2.3 KB) - added by rg 13 years ago.
Different patch that disables file/line number information
tt281-debuginfo-fastcore.patch Download (2.7 KB) - added by rurban 13 years ago.

Change History

  Changed 13 years ago by moritz

  • milestone set to 0.9.1

follow-ups: ↓ 3 ↓ 8 ↓ 9   Changed 13 years ago by jkeenan

Running make fulltest on Linux i386, I experienced exactly the same failure as reported by moritz.

/usr/bin/perl t/harness --gc-debug --running-make-test -f --runcore-tests

[snip output of -f except where failing]

t/op/debuginfo.........................
#   Failed test 'setfile and setline'
#   at t/op/debuginfo.t line 163.
#                   'Could not find non-existent sub no_such_function
# current instr.: 'main' pc 0 (xyz.pir:124)
# '
#     doesn't match '/\(xyz.pir:126\)/
# '
# './parrot -D40 -f --gc-debug  "/topdir/t/op/debuginfo_7.pir"' failed with exit code 1

#   Failed test 'setfile and setline'
#   at t/op/debuginfo.t line 176.
#                   'Could not find non-existent sub nsf
# current instr.: 'main' pc 0 (foo.p6:124)
# '
#     doesn't match '/\(foo.p6:128\)/
# '
# './parrot -D40 -f --gc-debug  "/topdir/t/op/debuginfo_8.pir"' failed with exit code 1
# Looks like you failed 2 tests of 8.
dubious
	Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 7-8
	Failed 2/8 tests, 75.00% okay
Failed Test      Stat Wstat Total Fail  List of Failed
-------------------------------------------------------------------------------
t/op/debuginfo.t    2   512     8    2  7-8
7 tests and 597 subtests skipped.
Failed 1/247 test scripts. 2/8373 subtests failed.
Files=247, Tests=8373, 300 wallclock secs (106.62 cusr + 31.26 csys = 137.88 CPU)
Failed 1/247 test programs. 2/8373 subtests failed.
make[1]: *** [testf] Error 255
make[1]: Leaving directory `/topdir'
make: [fulltest] Error 2 (ignored)

This was the only error I experienced to this point.

However, since I don't often run make fulltest, I should ask: Are there other make targets within fulltest that would have run subsequent to this point if -f had passed all its tests?

Thank you very much.
kid51

in reply to: ↑ 2 ; follow-up: ↓ 6   Changed 13 years ago by coke

Replying to jkeenan:

However, since I don't often run make fulltest, I should ask: Are there other make targets within fulltest that would have run subsequent to this point if -f had passed all its tests?

Look for the fulltest target in the Makefile; testf is the 3rd of many components for that target.

Changed 13 years ago by rg

Patch to fix the bug

  Changed 13 years ago by rg

I've just attached a patch that does fix the problem for me (all tests pass). Of course this will make the "fast" core a tiny bit slower for the sake of proper error reporting.

Changed 13 years ago by rg

Different patch that disables file/line number information

  Changed 13 years ago by rg

So since a lot of people don't like slowing down the fast core, patch2 is a patch that sets the pc to NULL thereby completely disabling the file and linenumber information for those cores. The tests are updated to reflect that fact. Since I'm on amd64, somebody else needs to please figure out which way the jit core goes.

in reply to: ↑ 3 ; follow-up: ↓ 7   Changed 13 years ago by jkeenan

Replying to coke:

Look for the fulltest target in the Makefile; testf is the 3rd of many components for that target.

So a failure in one test prevents make fulltest from going on to the next step -- correct?

in reply to: ↑ 6   Changed 13 years ago by rg

Replying to jkeenan:

So a failure in one test prevents make fulltest from going on to the next step -- correct?

Correct. So all the more reason to pick one of my patches or tell me how to make them acceptable ;)

in reply to: ↑ 2   Changed 13 years ago by jkeenan

Also failed with make testg

/usr/local/bin/perl t/harness --gc-debug --running-make-test -g --runcore-tests

[snip]

t/op/debuginfo.........................6/8 
#   Failed test 'setfile and setline'
#   at t/op/debuginfo.t line 163.
#                   'Could not find non-existent sub no_such_function
# current instr.: 'main' pc 0 (xyz.pir:124)
# '
#     doesn't match '/\(xyz.pir:126\)/
# '
# './parrot -g -D40 --gc-debug  "/home/jimk/work/parrot/t/op/debuginfo_7.pir"' failed with exit code 1

#   Failed test 'setfile and setline'
#   at t/op/debuginfo.t line 176.
#                   'Could not find non-existent sub nsf
# current instr.: 'main' pc 0 (foo.p6:124)
# '
#     doesn't match '/\(foo.p6:128\)/
# '
# './parrot -g -D40 --gc-debug  "/home/jimk/work/parrot/t/op/debuginfo_8.pir"' failed with exit code 1
# Looks like you failed 2 tests of 8.
t/op/debuginfo......................... Dubious, test returned 2 (wstat 512, 0x200)

in reply to: ↑ 2   Changed 13 years ago by jkeenan

Replying to jkeenan:

Running make fulltest on Linux i386, I experienced exactly the same failure as reported by moritz.

Situation remains the same on Linux i386 at r36804.

  Changed 13 years ago by rurban

The problem here is, that it should not be fixed in src/runops_cores.c.

Missing setline/setfile instrumentation in the fast runcore is a limitation, annotations should be used instead. language/perl6 uses annotations.

So the tests should be fixed to acknowledge that.

Changed 13 years ago by rurban

  Changed 13 years ago by coke

  • priority changed from normal to blocker

This test is also failing on darwin x86, which prevents 'make fulltest' from completing.

We really need to address this before the release.

  Changed 13 years ago by rurban

  • status changed from new to closed
  • resolution set to fixed

fix applied with r36820

tt281-debuginfo-fastcore.patch

  Changed 13 years ago by chromatic

  • status changed from closed to reopened
  • resolution fixed deleted

Skipping tests *does not fix tickets*. It never has and it never will. Reopening.

  Changed 13 years ago by coke

Even with this, the same test now fails in the 'testb' core, blocking 'make fulltest'

  Changed 13 years ago by whiteknight

Yes, this test is going to fail on *most* runcores right now because of underlying problems in the handling and updating of contexts. I can't imagine all these issues are going to be resolved before the release, we should TODO the test on all cores for right now until after the release when a solid fix can be developed and applied.

  Changed 13 years ago by coke

revision 36822 fails on testg instead.

  Changed 13 years ago by rurban

  • status changed from reopened to closed
  • resolution set to fixed

fixed with r36824

  Changed 13 years ago by coke

  • status changed from closed to reopened
  • resolution fixed deleted

To quote a previous comment:

Changed 80 minutes ago by chromatic 


status changed from closed to reopened
resolution fixed deleted
Skipping tests *does not fix tickets*. It never has and it never will. Reopening.

This doesn't FIX the issue, it just papers over it. Reopening ticket. Please don't close it again while we have skips in here.

  Changed 13 years ago by coke

  • priority changed from blocker to normal
  • milestone changed from 0.9.1 to 1.0

bumping milestone, since the next release won't show failing tests. (Leaving ticket open since the root cause still exists, let's try to fix it by 1.0)

  Changed 13 years ago by rurban

chromatic: what is your proposal to fix it then? make the fast runcore big and slow by adding for new src lines a setline op?

I said above: "The problem here is, that it should not be fixed in src/runops_cores.c.

Missing setline/setfile instrumentation in the fast runcore is a limitation, annotations should be used instead. language/perl6 uses annotations."

We already have annotations, the test is wrong so it should be skipped. What am I missing here?

  Changed 13 years ago by jkeenan

  • cc chromatic, whiteknight added

Currently, 3 tests in t/op/debuginfo.t are SKIPped under various conditions:

$ grep -n -A5 SKIP t/op/debuginfo.t 
30:SKIP: {
31-skip "disabled on fast-core",1 if $ENV{TEST_PROG_ARGS} =~ /--runcore=(fast|cgoto)/;
32-
33-pasm_output_like( <<'CODE', <<"OUTPUT", "getline, getfile" );
34-.pcc_sub main:
35-    getfile S0
--
170:SKIP: {
171-skip "disabled on this core",2 if $ENV{TEST_PROG_ARGS} =~ /--runcore=(fast|cgoto|jit|switch)/;
172-
173-# See "RT #43269 and .annotate
174-pir_error_output_like( <<'CODE', <<"OUTPUT", "setfile and setline" );
175-.sub main :main

If I understand chromatic's point correctly, these files should be TODOed rather than being SKIPped. If so, let's change them from SKIP to TODO. Comments?

(Well, here's a comment: If we change them to TODO, they will probably 'pass unexpectedly' during make test and some other cores and make targets.)

kid51

  Changed 13 years ago by whiteknight

  • status changed from reopened to closed
  • resolution set to fixed

This test failure was fixed yesterday in r39576 by the patch from mikehh++. I haven't heard any other reports of failures or TODO PASSED stuff or anything since then. Resolving.

Note: See TracTickets for help on using tickets.