Ticket #1420 (closed bug: fixed)

Opened 5 years ago

Last modified 4 years ago

Failed assertion when running 240th test in 01-regex.t in GGE

Reported by: masak Owned by:
Priority: normal Milestone:
Component: GC Version: 2.0.0
Severity: fatal Keywords: fail, crash, assertion, stacktrace
Cc: Language: perl6
Patch status: applied Platform: mac

Description

Following these steps I can create Parrot to abort abnormally.

$ git clone git://github.com/masak/gge.git
$ cd gge
$ git checkout ed12aa
$ export PERL6LIB=`pwd`/lib
$ perl6 Configure 
$ make
$ perl6 t/perl6regex/01-regex.t 

Here's the stacktrace I get.

[snip]
ok 238 - [metachars:238] digit
ok 239 - [metachars:239] digit
src/gc/api.c:245: failed assertion 'PObj_is_PMC_TEST(obj)'
Backtrace - Obtained 32 stack frames (max trace depth is 32).
0   libparrot.dylib                     0x0000000100af4e03 Parrot_print_backtrace + 35
1   libparrot.dylib                     0x0000000100af4f37 Parrot_confess + 135
2   libparrot.dylib                     0x0000000100b0472f Parrot_gc_mark_PMC_alive_fun + 127
3   libparrot.dylib                     0x0000000100cd6f73 Parrot_Object_mark + 115
4   libparrot.dylib                     0x0000000100b08b9d mark_special + 477
5   libparrot.dylib                     0x0000000100b0658a Parrot_gc_mark_PObj_alive + 186
6   libparrot.dylib                     0x0000000100b09620 trace_mem_block + 320
7   libparrot.dylib                     0x0000000100b096e7 trace_system_stack + 119
8   libparrot.dylib                     0x0000000100b0975a trace_system_areas + 106
9   libparrot.dylib                     0x0000000100b08ff5 Parrot_gc_trace_root + 1109
10  libparrot.dylib                     0x0000000100b06ee2 gc_ms_trace_active_PMCs + 66
11  libparrot.dylib                     0x0000000100b07190 gc_ms_mark_and_sweep + 288
12  libparrot.dylib                     0x0000000100b044ad Parrot_gc_mark_and_sweep + 77
13  libparrot.dylib                     0x0000000100c321cd mem_allocate + 205
14  libparrot.dylib                     0x0000000100b05a75 Parrot_gc_allocate_string_storage + 213
15  libparrot.dylib                     0x0000000100a599e8 Parrot_str_new_init + 328
16  libparrot.dylib                     0x0000000100a5a53d Parrot_str_new + 173
17  perl6_ops.bundle                    0x00000001015e6288 Parrot_transform_to_p6opaque_p + 104
18  libparrot.dylib                     0x0000000100b71694 runops_fast_core + 180
19  libparrot.dylib                     0x0000000100b7019c runops_int + 252
20  libparrot.dylib                     0x0000000100b19e32 runops + 370
21  libparrot.dylib                     0x0000000100b0f7ae Parrot_pcc_invoke_from_sig_object + 430
22  libparrot.dylib                     0x0000000100b0f962 Parrot_pcc_invoke_sub_from_c_args + 386
23  libparrot.dylib                     0x0000000100b699be run_sub + 254
24  libparrot.dylib                     0x0000000100b69cdb do_1_sub_pragma + 763
25  libparrot.dylib                     0x0000000100b69ebd do_sub_pragmas + 445
26  libparrot.dylib                     0x0000000100b69fbc PackFile_fixup_subs + 124
27  libparrot.dylib                     0x0000000100d282fa imcc_compile + 1386
28  libparrot.dylib                     0x0000000100d283c5 imcc_compile_pir_ex + 149
29  libparrot.dylib                     0x0000000100b5d3ab pcf_P_Jt + 203
30  libparrot.dylib                     0x0000000100c5dda8 Parrot_NCI_invoke + 296
31  libparrot.dylib                     0x0000000100a73100 Parrot_invokecc_p + 144
Abort trap

I wouldn't be surprised if exact Rakudo/Parrot versions and platforms play into this bug. I'm running Rakudo 4add64 on Parrot r43600. I'm on Mac OS X 10.6.2. I have 4 GB of RAM.

The assertion failure cannot be triggered simply by running test 240 in 01-regex.t. This is consistent with the observation that it seems to occur during a GC run. Running all of the 239 tests takes... a while; sorry about that. On the upside, the assertion failure seems very reliable.

The steps 'perl6 Configure' and 'make' are also necessary for the effect to occur. I tried without them, and then test 240 runs fine.

Change History

  Changed 5 years ago by lithos

This looks very much like another case triggering the bug #1393.

in reply to: ↑ description   Changed 5 years ago by jkeenan

Replying to masak:

In the tt1393_retcon branch we're testing a patch that is intended to correct a problem that is somewhat similar to the one you reported here.

Would it be possible for you to build Parrot from that branch, then perform the other steps needed to generate your bug?

Thank you very much.

kid51

follow-up: ↓ 4   Changed 4 years ago by masak

Would it be possible for you to build Parrot from that branch, then perform the other steps needed to generate your bug?

Yep; did that. Problem didn't re-occur. So either I messed up something, or that particular issue is fixed. :)

in reply to: ↑ 3   Changed 4 years ago by jkeenan

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

Replying to masak:

Would it be possible for you to build Parrot from that branch, then perform the other steps needed to generate your bug?

Yep; did that. Problem didn't re-occur. So either I messed up something, or that particular issue is fixed. :)

In trunk, I just applied the patch submitted in TT #1393. That ticket will remain open for a few days to record any failures, but it looks like it's okay for us to close this ticket now. Closing.

Thank you very much.

kid51

Note: See TracTickets for help on using tickets.