On Thursday 04 September 2008 11:40:36 Moritz Lenz wrote:
> # New Ticket Created by Moritz Lenz
> # Please include the string: [perl #58578]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58578 >
>
>
> Rakudo r30754 segfaults while running some regexe tests.
> How to reproduce:
>
> cd languages/perl6/t/spec/
> vim t/spec/S05-mass/pge-tests.t # set variable $segfault_limit to 745
> svn up -r 22156
> cd ../..
> ../../parrot perl6.pbc t/spec/S05-mass/pge-tests.t
>
> wait patiently until it dies. Adding -G doesn't remove that segfault.
Run it through GDB, and it looks like Parrot runs out of stack space
recursivelyly throwing exceptions. If someone modifies Rakudo not to catch
the topmost exception, I bet we could track this down faster.
(I also modified the test file to skip the first 500+ tests, and I still get
weird segfaults here.)
Ah, I've seen this sort of thing before.
#152 0xb7c484c1 in fail_if_type_exists (interp=0x804f040, name=0xb7285c48)
at src/oo.c:619
#153 0xb7c48534 in Parrot_oo_register_type (interp=0x804f040, name=0xb7285c48)
at src/oo.c:649
#154 0xb7de95da in init_class_from_hash (interp=0x804f040, self=0xb7285af8,
info=0xb7285938) at ./src/pmc/class.pmc:222
#155 0xb7deb038 in Parrot_Class_init_pmc (interp=0x804f040, pmc=0xb7285af8,
init_data=0xb7285c48) at ./src/pmc/class.pmc:512
#156 0xb7c53f01 in pmc_new_init (interp=0x804f040, base_type=49,
init=0xb7285c48) at src/pmc.c:368
#157 0xb7bba048 in Parrot_newclass_p_p (cur_opcode=0xb7ab0b24,
interp=0x804f040) at src/ops/object.ops:249
#158 0xb7c5490c in runops_slow_core (interp=0x804f040, pc=0xb7ab0b24)
at src/runops_cores.c:222
#159 0xb7c15e49 in runops_int (interp=0x804f040, offset=3289)
---Type <return> to continue, or q <return> to quit---
at src/interpreter.c:937
#160 0xb7c16723 in runops (interp=0x804f040, offs=3289) at src/inter_run.c:101
#161 0xb7c169ef in runops_args (interp=0x804f040, sub=0xb728d268,
obj=0x80a7f50, meth_unused=0x0, sig=0xb7e884e8 "vPS",
ap=0xbf82f8ac "@��<[EMAIL PROTECTED]@��<\020n�\024")
at src/inter_run.c:236
#162 0xb7c16b3c in Parrot_runops_fromc_args (interp=0x804f040, sub=0xb728d268,
sig=0xb7e884e8 "vPS") at src/inter_run.c:300
#163 0xb7c026aa in Parrot_ex_throw_from_c (interp=0x804f040,
exception=0xb728ce40) at src/exceptions.c:292
#164 0xb7c0277e in Parrot_ex_throw_from_c_args (interp=0x804f040,
ret_addr=0x0, exitcode=20,
format=0xb7e8b644 "Class %Ss already registered!\n")
at src/exceptions.c:339
#165 0xb7c484c1 in fail_if_type_exists (interp=0x804f040, name=0xb728d134)
at src/oo.c:619
#166 0xb7c48534 in Parrot_oo_register_type (interp=0x804f040, name=0xb728d134)
at src/oo.c:649
#167 0xb7de95da in init_class_from_hash (interp=0x804f040, self=0xb728d08c,
info=0xb728ce94) at ./src/pmc/class.pmc:222
#168 0xb7deb038 in Parrot_Class_init_pmc (interp=0x804f040, pmc=0xb728d08c,
init_data=0xb728d134) at ./src/pmc/class.pmc:512
#169 0xb7c53f01 in pmc_new_init (interp=0x804f040, base_type=49,
init=0xb728d134) at src/pmc.c:368
#170 0xb7bba048 in Parrot_newclass_p_p (cur_opcode=0xb7ab0b24,
interp=0x804f040) at src/ops/object.ops:249
This co-recurses for a while, and then Parrot runs out of contexts, and *that*
exception loops for a while. An exception handler around here is wonky in
that it causes an attempt to register a new type. Fun.
-- c
