test 12 of t/pmc/eval.t fails in testr (passes in other runcores)

[mikehh]

In testr from fulltest at r42082 - Ubuntu 9.10 beta (updated) amd64:

#   Failed test 'eval.thaw'
#   at t/pmc/eval.t line 397.
# Exited with error code: 139
# Received:
# hello from foo_1
# hello from foo_1
# Segmentation fault
#
# Expected:
# hello from foo_1
# hello from foo_1
#
# Looks like you failed 1 test of 17.

t/pmc/eval.t ........................
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/17 subtests


Test Summary Report
-------------------
t/pmc/eval.t                       (Wstat: 256 Tests: 17 Failed: 1)
  Failed test:  12
  Non-zero exit status: 1
Files=220, Tests=6703, 60 wallclock secs ( 2.79 usr  0.47 sys + 55.35 cusr 34.64 csys = 93.25 CPU)
Result: FAIL
make[1]: *** [testr] Error 1

I first recorded the failure at r42049

bisecting:

the test passes at r42037 and fails at r42038

[mikehh]

marked the failing test as TODO in r42087

[mikehh]

The test passes on Ubuntu 9.04 i386 (g++)

All tests PASS (pre/post-config, smoke (#29410), fulltest) at r42132 - Ubuntu 9.04 i386 (g++)
in testr (fulltest) t/pmc/eval.t - TODO passed: 12

at the same revision r42132 with Ubuntu 9.10 RC amd64

mhb@mhb-desktop:~/parrot$ perl t/harness -r t/pmc/eval.t
t/pmc/eval.t .. 8/17
not ok 12 - eval.thaw # TODO fails eval.thaw test in testr with Segmentation fault - TT #1142
t/pmc/eval.t .. ok
All tests successful.
Files=1, Tests=17,  3 wallclock secs ( 0.01 usr  0.00 sys +  0.38 cusr  0.30 csys =  0.69 CPU)
Result: PASS

the Segmentation fault appears to be specific to amd64

[jkeenan]

Replying to mikehh:

All tests PASS (pre/post-config, smoke (#29410), fulltest) at r42132 - Ubuntu 9.04 i386 (g++)
in testr (fulltest) t/pmc/eval.t - TODO passed: 12

I, too, got this result on Linux/i386 (i.e., no FAILs on make fulltest).

the Segmentation fault appears to be specific to amd64

I concur.

kid51

[mikehh]

I have run the test on Ubuntu 9.04 amd64, Ubuntu 9.10 amd64 and Ubuntu 9.10 i386

On all three platforms I built using g++ and gcc with both with and without --optimize

On Ubuntu 9.10 the builds were with gcc/g++ 4.4.1 and on 9.04 gcc/g++ 4.3.4

The test fails (not ok) with gcc builds on amd64

It passes g++ builds on amd64 and all builds on i386 (TODO passed: 12)

I have had other reports of it passing on i386 platforms

In conclusion the test fails only on amd64 gcc builds (both with or without --optimize) with both Ubuntu 9.04 amd64 and Ubuntu 9.10 amd64

I am not quite sure how to TODO the test specifically for amd64 with gcc but not g++, or of course, the better solution, fix the .pbc code so that it does not cause a Segmentation fault.

[mikehh]

for those who can interpret these things I generated a backtrace.

run on parrot r42522 on Ubuntu 9.10 amd64 built with
perl Configure.pl --optimize --test --maintainer --configure_trace

(I first ran ./parrot t/pmc/eval_11.pbc to set up the relevant file)

mhb@mhb-desktop:~/t.parrot$ ./parrot  t/pmc/eval_12.pbc
hello from foo_1
Segmentation fault (core dumped)
mhb@mhb-desktop:~/t.parrot$ gdb ./parrot core
...
Core was generated by `./parrot t/pmc/eval_12.pbc'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000000021d2080 in ?? ()
(gdb) ba
#0  0x00000000021d2080 in ?? ()
#1  0x00007fb026df3731 in Parrot_set_returns_pc (cur_opcode=0x2231fd0, interp=0x213a080) at src/ops/core.ops:582
#2  0x00007fb026e67164 in runops_slow_core (interp=0x213a080, runcore=<value optimised out>, pc=0x2231fd0) at src/runcore/cores.c:844
#3  0x00007fb026e661c1 in runops_int (interp=0x213a080, offset=<value optimised out>) at src/runcore/main.c:546
#4  0x00007fb026e2944a in runops (interp=<value optimised out>, offs=<value optimised out>) at src/call/ops.c:97
#5  0x00007fb026e23bd9 in Parrot_pcc_invoke_from_sig_object (interp=0x213a080, sub_obj=<value optimised out>, call_object=<value optimised out>) at src/call/pcc.c:296
#6  0x00007fb026e23cd3 in Parrot_pcc_invoke_sub_from_c_args (interp=0x213a080, sub_obj=0x21dac58, sig=<value optimised out>) at src/call/pcc.c:74
#7  0x00007fb026f500de in imcc_run_pbc (interp=0x213a080, sourcefile=0x7fffcd529640 "t/pmc/eval_12.pbc", argc=<value optimised out>, argv=<value optimised out>) at compilers/imcc/main.c:793
#8  imcc_run (interp=0x213a080, sourcefile=0x7fffcd529640 "t/pmc/eval_12.pbc", argc=<value optimised out>, argv=<value optimised out>) at compilers/imcc/main.c:1076
#9  0x0000000000400c02 in main (argc=1, argv=0x7fffcd528760) at src/main.c:60

I am going to try this on an build without --optimize to see if it makes more sense

[mikehh]

run on parrot r42523 on Ubuntu 9.10 amd64 built with:
perl Configure.pl --test --maintainer --configure_trace

same as previous comment:

#0  0x0000000001ebf080 in ?? ()
#1  0x00007f97ba9ec22e in Parrot_set_returns_pc (cur_opcode=0x1f1efd0, interp=0x1e27080) at src/ops/core.ops:582
#2  0x00007f97bab10a70 in runops_slow_core (interp=0x1e27080, runcore=0x1ec86f0, pc=0x1f1efd0) at src/runcore/cores.c:844
#3  0x00007f97bab0f056 in runops_int (interp=0x1e27080, offset=0) at src/runcore/main.c:546
#4  0x00007f97baaaf89e in runops (interp=0x1e27080, offs=0) at src/call/ops.c:97
#5  0x00007f97baaa63e5 in Parrot_pcc_invoke_from_sig_object (interp=0x1e27080, sub_obj=0x1ec7c58, call_object=0x1ec7ca8) at src/call/pcc.c:296
#6  0x00007f97baaa5bcf in Parrot_pcc_invoke_sub_from_c_args (interp=0x1e27080, sub_obj=0x1ec7c58, sig=0x7f97bacf349a "P->") at src/call/pcc.c:74
#7  0x00007f97baa86610 in Parrot_runcode (interp=0x1e27080, argc=1, argv=0x7fff0ee55f30) at src/embed.c:828
#8  0x00007f97bacc659e in imcc_run_pbc (interp=0x1e27080, obj_file=0, output_file=0x0, argc=1, argv=0x7fff0ee55f30) at compilers/imcc/main.c:793
#9  0x00007f97bacc720e in imcc_run (interp=0x1e27080, sourcefile=0x7fff0ee5763b "t/pmc/eval_12.pbc", argc=1, argv=0x7fff0ee55f30) at compilers/imcc/main.c:1076
#10 0x0000000000400c30 in main (argc=1, argv=0x7fff0ee55f30) at src/main.c:60

[mikehh]

fixed the TODO in testr so that it only TODO's for testr and amd64 with cc/gcc and not g++ in r42549

I am not closing the ticket as the Segmentation fault still occurs on builds with gcc on amd64

[mikehh]

The Segmentation fault no longer occurs at r42600 - removed the TODO on the test in r42602

the relevant fix was between r42574 and r42584 - the test failed (not ok) at r42574 and TODO passed at r42584 on amd64 built with gcc.

I am closing this ticket

[plobsing]

Replying to mikehh:

I encountered this error one too many times making changes that should have no direct effect on Eval PMC. After investigating, here's what I'm fairly sure is happening:

• Thawing an Eval PMC creates a new PackFile to put code into. Having more than one packfile is not something that happens frequently in parrot because most operations append to interp.initial_pf. (see compile_or_load_file() and Packfile_append_pbc() in src/packfile.c)
• Constant segment PMCs are not thawed as constants because this leads to bugs with constant PMCs pointing to non-constant PMCs. (see PackFile_Constant_unpack_pmc() in src/packfile.c)
• The new packfile is not interp.initial_pf and so its constant segment is not marked by GC. (see mark_const_subs() in src/packfile.c).
• If the object sizes relative to the GC pool sizes, startup and thaw object allocations, and phase of the moon are just right; a GC sweep will occur after thawing the Eval PMC's packfile but before the Eval PMC's code has finished executing, leading to all constants in the Eval's packfile being collected prematurely (in this case there is only one: the FixedIntegerArray used by set_returns).

Also, I can reproduce this problem (well, a very similar problem - it only prints the first "hello from foo_1") against trunk (r43346) on Linux both i686 and amd64 by running:

make test
./parrot t/pmc/eval_11.pir
./parrot -R gcdebug t/pmc/eval_12.pir

My conclusions:

• This problem is not fixed, it is simply hidden.
• This problem is not specific to testr or amd64, it just presented itself there.
• This problem should go away (not just hide) when packfiles are GCable as per PDD13 (and therefor able to mark their constant segments while still live).

[mikehh]

I removed a TODO (merged from branch pmc_freeze_cleanup at r43434) on this test as it passes on all platforms I can test on. Removed TODO at r43445.

I would appreciate any reports of this test failing on any platforms.

[mikehh]

Since the merge of the orderedhash_revamp branch at r43686 I am getting this test failing again in testr with gcc builds on Ubuntu 9.10 amd64, but it passes on g++ builds on the same platform.

#   Failed test 'eval.thaw'
#   at t/pmc/eval.t line 397.
# Exited with error code: 139
# Received:
# hello from foo_1
# Segmentation fault
#
# Expected:
# hello from foo_1
# hello from foo_1
#


Test Summary Report
-------------------
t/pmc/eval.t                       (Wstat: 256 Tests: 17 Failed: 1)
  Failed test:  12
  Non-zero exit status: 1
Files=223, Tests=7085, 51 wallclock secs ( 2.56 usr  0.58 sys + 40.53 cusr 24.85 csys = 68.52 CPU)
Result: FAIL
make[1]: *** [testr] Error 1

note that the Segmentation fault seems to occur earlier than it occurred when the error first came up and seemed to be resolved.

[mikehh]

after running ./parrot t/pmc/eval_11.pbc to create the file

with the gcc build (with --optimize) (r43600) I get:

./parrot -t t/pmc/eval_12.pbc
     0 set S1, "/tmp/VzIm7O67dC"                                        S1="(null)"
     3 stat I0, S1, 1                                        I0=0 S1="/tmp/VzIm7O67dC"
     7 open P1, S1, "r"                                        P1=PMCNULL S1="/tmp/VzIm7O67dC"
    11 read S0, P1, I0                                        S0="(null)" P1=FileHandle=PMC(0x1b69ee8) I0=1488
    15 close P1                                        P1=FileHandle=PMC(0x1b69ee8)
    17 thaw P0, S0                                        P0=PMCNULL S0="\x{fe}PBC\r\n\x{1a}\n\b\x{0}\x{0}\x{2}\x{0}\x{0}\x{6}\x{0}\x{0}\x{0}\x{0}\x{0}"
    20 set_args PC4
    22 get_results PC4
    24 invokecc P0                                        P0=Eval=PMC(0x1b69f60)
     0 print "hello from foo_1\n"
       GC mark
       GC collect
hello from foo_1
Segmentation fault

with the g++ build (with --optimize) (r43599) I get:

./parrot -t t/pmc/eval_12.pbc
     0 set S1, "/tmp/VZrgPfJ8Hg"                                        S1="(null)"
     3 stat I0, S1, 1                                        I0=0 S1="/tmp/VZrgPfJ8Hg"
     7 open P1, S1, "r"                                        P1=PMCNULL S1="/tmp/VZrgPfJ8Hg"
    11 read S0, P1, I0                                        S0="(null)" P1=FileHandle=PMC(0xf8cce0) I0=1488
    15 close P1                                        P1=FileHandle=PMC(0xf8cce0)
    17 thaw P0, S0                                        P0=PMCNULL S0="\x{fe}PBC\r\n\x{1a}\n\b\x{0}\x{0}\x{2}\x{0}\x{0}\x{6}\x{0}\x{0}\x{0}\x{0}\x{0}"
    20 set_args PC4
    22 get_results PC4
    24 invokecc P0                                        P0=Eval=PMC(0xf8cd58)
     0 print "hello from foo_1\n"
hello from foo_1
     2 set_returns PC1
     4 returncc
    26 get_global P0, "foo_1"                                        P0=Eval=PMC(0xf8cd58)
    29 set_args PC4
    31 get_results PC4
    33 invokecc P0                                        P0=Sub=PMC(0xf8ce70 pc:0)
     0 print "hello from foo_1\n"
hello from foo_1
     2 set_returns PC1
     4 returncc
    35 set_returns PC4
    37 returncc
FileHandle objects (like stdout and stderr)are about to be closed, so clearing trace flags.

so it looks to me that the Segmentation fault is generated by GC mark/GC collect

[mikehh]

I tested at r43654 and gcc still fails the test on amd64 (with and without --optimize). It PASSes on g++ builds and on i386 builds (all variants).

Running ./parrot -t t/pmc/eval_12.pbc (after ./parrot t/pmc/eval_11.pbc) built using gcc on Ubuntu 9.10 i386 is pretty much the same as the g++ result in the previous comment (different addresses and temp file of course) but otherwise the same. i.e. it does not invoke the GC mark/GC collect whereas the gcc builds on amd64 does.

Note the comment by plobsing++ above on the GC mark/collect.

BTW the branch orderedhash_revamp was merged at r43586 (not r43686) as per an earlier comment

[mikehh]

This ticket appears to be stale.

Unless there are any objections I will be closing this ticket in a day or so.

Cheers,

Michael (mikehh)

[mikehh]

I haven't seen any problems with this test for the last 3 months or so. Closing Ticket.

[plobsing]

I've forced a GC run in the appropriate place. Now it should fail everywhere for everyone.

[plobsing]

Recent changes caused this bug to stop manifesting. Eval PMC now marks the constant table, not the fixup table.

So far as I can tell, this bug is now closed. mikehh++ for noticing.