# New Ticket Created by Will Coleda # Please include the string: [perl #60128] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60128 >
Trying to track down a segfault that is occurring for me in parrot (triggered by partcl): After getting partcl (http://code.google.com/p/partcl/wiki/PartclSource)[0], and then the spectests (http://code.google.com/p/partcl/wiki/TestingPartcl), I can trigger it with: ../../parrot tcl.pbc t_tcl/namespace-old.test I've tried stripping down the amount of tcl[1] needed to generate that, but it's hard to keep the segfault from vanishing. I did find that running with -G makes it go away; Using the techniques here: http://www.oreillynet.com/onlamp/blog/2007/10/how_to_debug_a_gc_problem_in_p.html, I see the segfault here: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6b428d0 (LWP 945)] 0xb7d20ff8 in ascii_compute_hash (interp_unused=0x804f040, source_string=0xb5489c30, seed=3793) at src/charset/ascii.c:769 769 hashval += *buffptr++; So the problem isn't with a PMC, it's with a STRING. So, instead of setting a conditional breakpoint on pmc_new, I do so on new_string_header; but this is glacially slow. I get no output in the time in normally takes the whole test to segfault. Anyone have better ideas on how to track this segfault down? I'm going to leave the conditional breakpoint in gdb running overnight on feather, but don't hold out hope. Regards. [0] I'm doing this against Revision: 32150 in trunk, though. [1] 849 lines for the test file; 3384 lines for the test harness. And that's on top of all the PIR required to run the tcl in the first place. -- Will "Coke" Coleda
