I've been getting segfaults in this area recently. The trace is a bit
different but I guess it's related. It seems that flag_map in gc_mark is no
longer allocated so I get segfault.

(lldb) r
There is a running process, kill it and restart?: [Y/n] y
Process 75673 exited with status = 9 (0x00000009)
Process 75691 launched: '/Users/llfourn/src/rakudo/install/bin/moar'
(x86_64)
Process 75691 stopped
* thread #1: tid = 0x23cfc68, 0x0000000100063ca4
libmoar.dylib`gc_mark(tc=0x0000000100500290, st=0x0000000101004f40,
data=<unavailable>, worklist=0x000000010d27c1a0) + 84 at
MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x10a72533)
    frame #0: 0x0000000100063ca4
libmoar.dylib`gc_mark(tc=0x0000000100500290, st=0x0000000101004f40,
data=<unavailable>, worklist=0x000000010d27c1a0) + 84 at MVMCallCapture.c:55
   52          MVMuint16  count = ctx->arg_count;
   53          MVMuint16  i, flag;
   54          for (i = 0, flag = 0; i < count; i++, flag++) {
-> 55              if (flag_map[flag] & MVM_CALLSITE_ARG_NAMED) {
   56                  /* Current position is name, then next is value. */
   57                  MVM_gc_worklist_add(tc, worklist, &ctx->args[i].s);
   58                  i++;
(lldb) bt
* thread #1: tid = 0x23cfc68, 0x0000000100063ca4
libmoar.dylib`gc_mark(tc=0x0000000100500290, st=0x0000000101004f40,
data=<unavailable>, worklist=0x000000010d27c1a0) + 84 at
MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x10a72533)
  * frame #0: 0x0000000100063ca4
libmoar.dylib`gc_mark(tc=0x0000000100500290, st=0x0000000101004f40,
data=<unavailable>, worklist=0x000000010d27c1a0) + 84 at MVMCallCapture.c:55
    frame #1: 0x000000010003f002
libmoar.dylib`MVM_gc_mark_collectable(tc=<unavailable>,
worklist=<unavailable>, new_addr=<unavailable>) + 1714 at collect.c:399
    frame #2: 0x000000010003e883
libmoar.dylib`process_worklist(tc=0x0000000100500290,
worklist=0x000000010d27c1a0, wtp=0x00007fff5fbff468, gen='\0') + 899 at
collect.c:313
    frame #3: 0x000000010003e324
libmoar.dylib`MVM_gc_collect(tc=0x0000000100500290,
what_to_do=<unavailable>, gen=<unavailable>) + 820 at collect.c:129
    frame #4: 0x000000010003b703
libmoar.dylib`run_gc(tc=0x0000000100500290, what_to_do='\0') + 131 at
orchestrate.c:304
    frame #5: 0x000000010003b4c8
libmoar.dylib`MVM_gc_enter_from_allocator(tc=0x0000000100500290) + 984 at
orchestrate.c:438
    frame #6: 0x000000010003bca8 libmoar.dylib`MVM_gc_allocate_zeroed
[inlined] MVM_gc_allocate_nursery(tc=<unavailable>, size=<unavailable>) +
52 at allocation.c:32
    frame #7: 0x000000010003bc74 libmoar.dylib`MVM_gc_allocate_zeroed
[inlined] MVM_gc_allocate(tc=<unavailable>) + 23 at allocation.h:13
    frame #8: 0x000000010003bc5d
libmoar.dylib`MVM_gc_allocate_zeroed(tc=0x0000000100500290, size=40) + 13
at allocation.c:49
    frame #9: 0x000000010003bf44
libmoar.dylib`MVM_gc_allocate_object(tc=0x0000000100500290,
st=<unavailable>) + 84 at allocation.c:86
    frame #10: 0x000000010005813f libmoar.dylib`allocate(tc=<unavailable>,
st=<unavailable>) + 15 at P6opaque.c:60
    frame #11: 0x0000000100050d27 libmoar.dylib`MVM_repr_box_str [inlined]
MVM_repr_alloc_init(tc=0x0000000100500290, type=0x0000000101626fc0) + 14 at
reprconv.c:13
    frame #12: 0x0000000100050d19
libmoar.dylib`MVM_repr_box_str(tc=0x0000000100500290,
type=0x0000000101626fc0, val=<unavailable>) + 73 at reprconv.c:586
    frame #13: 0x0000000100009c07
libmoar.dylib`MVM_exception_backtrace(tc=0x0000000100500290,
ex_obj=<unavailable>) + 1111 at exceptions.c:407
    frame #14: 0x0000000100017488
libmoar.dylib`MVM_interp_run(tc=0x0000000100500290,
initial_invoke=<unavailable>, invoke_data=<unavailable>) + 47320 at
interp.c:3830
    frame #15: 0x00000001000c8305
libmoar.dylib`MVM_vm_run_file(instance=<unavailable>,
filename=<unavailable>) + 181 at moar.c:304
    frame #16: 0x000000010000170a moar`main(argc=<unavailable>,
argv=0x00007fff5fbff8e8) + 666 at main.c:191
    frame #17: 0x00007fff900c05ad libdyld.dylib`start + 1
    frame #18: 0x00007fff900c05ad libdyld.dylib`start + 1
(lldb) fr v
(MVMThreadContext *) tc = 0x0000000100500290
(MVMSTable *) st = 0x0000000101004f40
(void *) data = <variable not available>

(MVMGCWorklist *) worklist = 0x000000010d27c1a0
(MVMCallCaptureBody *) body = <no location, value may have been optimized
out>

(MVMArgProcContext *) ctx = 0x000000010a6f3c00
(MVMuint16) flag = 0
(MVMuint16) i = 0
(MVMuint16) count = <variable not available>

(MVMuint8 *) flag_map = 0x0000000010a72533 ""
(lldb) p flag_map
(MVMuint8 *) $6 = 0x0000000010a72533 ""
(lldb) p flag_map[0]
error: Couldn't apply expression side effects : Couldn't dematerialize a
result variable: couldn't read its memory

On Sun, Jul 10, 2016 at 12:19 AM jn...@jnthn.net via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Tue Jul 05 17:51:46 2016, ug...@cpan.org wrote:
> > Note that the final decode-base64 candidate shows the correct results
> > when debugging statements are added
> >
> > This gist also shows a small change that makes it produce the correct
> > values but it still segfaults more often than not
> > https://gist.github.com/ugexe/baa168a641894a0731595c812724f76d
>
> Having dug into it a little, I'm not sure that the new multi-caching stuff
> has caused this, so much as uncovered it (perhaps by moving GC collection
> points). The valgrind output is as follows:
>
>     ok 1 - decoding the empty string
>     ok 2 - decoding "A"
>     not ok 3 - decoding "Ab"
>
> # Failed test 'decoding "Ab"'
> # at t/01-basic.t line 29
>     # expected: 'Ab'
>     #      got: 'A'
>     not ok 4 - decoding "Abc"
>
> # Failed test 'decoding "Abc"'
> # at t/01-basic.t line 30
>     # expected: 'Abc'
>     #      got: 'A'
> ==19699== Invalid read of size 8
> ==19699==    at 0x4FF2B3E: gc_mark (MVMCallCapture.c:51)
> ==19699==    by 0x4FC6BF5: process_worklist (collect.c:313)
> ==19699==    by 0x4FC71A0: MVM_gc_collect (collect.c:129)
> ==19699==    by 0x4FC2735: run_gc (orchestrate.c:304)
> ==19699==    by 0x4FC320D: MVM_gc_enter_from_allocator (orchestrate.c:438)
> ==19699==    by 0x4FC3627: MVM_gc_allocate_nursery (allocation.c:32)
> ==19699==    by 0x4FC39ED: MVM_gc_allocate_frame (allocation.c:99)
> ==19699==    by 0x4FA749F: MVM_frame_force_to_heap (frame.c:657)
> ==19699==    by 0x4FA8BEB: MVM_frame_capturelex (frame.c:1035)
> ==19699==    by 0x4F98D8F: MVM_interp_run (interp.c:1070)
> ==19699==    by 0x505E3F8: MVM_vm_run_file (moar.c:304)
> ==19699==    by 0x401036: main (main.c:191)
> ==19699==  Address 0x658f9d0 is 0 bytes inside a block of size 32 free'd
> ==19699==    at 0x4C2BDEC: free (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==19699==    by 0x4FF2CDA: MVM_free (alloc.h:29)
> ==19699==    by 0x4FF2CDA: gc_free (MVMCallCapture.c:78)
> ==19699==    by 0x4FC72D3: MVM_gc_collect_free_nursery_uncopied
> (collect.c:580)
> ==19699==    by 0x4FC2976: run_gc (orchestrate.c:328)
> ==19699==    by 0x4FC320D: MVM_gc_enter_from_allocator (orchestrate.c:438)
> ==19699==    by 0x4FC3627: MVM_gc_allocate_nursery (allocation.c:32)
> ==19699==    by 0x4FC39ED: MVM_gc_allocate_frame (allocation.c:99)
> ==19699==    by 0x4FA749F: MVM_frame_force_to_heap (frame.c:657)
> ==19699==    by 0x4FA8D4C: MVM_frame_takeclosure (frame.c:1051)
> ==19699==    by 0xEA66105: ???
> ==19699==    by 0x50342B8: MVM_jit_enter_code (compile.c:136)
> ==19699==    by 0x4F938F0: MVM_interp_run (interp.c:5456)
> ==19699==
> ==19699== Invalid read of size 1
> ==19699==    at 0x4FF2A7D: gc_mark (MVMCallCapture.c:55)
> ==19699==    by 0x4FC6BF5: process_worklist (collect.c:313)
> ==19699==    by 0x4FC71A0: MVM_gc_collect (collect.c:129)
> ==19699==    by 0x4FC2735: run_gc (orchestrate.c:304)
> ==19699==    by 0x4FC320D: MVM_gc_enter_from_allocator (orchestrate.c:438)
> ==19699==    by 0x4FC3627: MVM_gc_allocate_nursery (allocation.c:32)
> ==19699==    by 0x4FC39ED: MVM_gc_allocate_frame (allocation.c:99)
> ==19699==    by 0x4FA749F: MVM_frame_force_to_heap (frame.c:657)
> ==19699==    by 0x4FA8BEB: MVM_frame_capturelex (frame.c:1035)
> ==19699==    by 0x4F98D8F: MVM_interp_run (interp.c:1070)
> ==19699==    by 0x505E3F8: MVM_vm_run_file (moar.c:304)
> ==19699==    by 0x401036: main (main.c:191)
> ==19699==  Address 0xb36cc70 is 0 bytes inside a block of size 1 free'd
> ==19699==    at 0x4C2BDEC: free (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==19699==    by 0x4FF2CD1: MVM_free (alloc.h:29)
> ==19699==    by 0x4FF2CD1: gc_free (MVMCallCapture.c:77)
> ==19699==    by 0x4FC72D3: MVM_gc_collect_free_nursery_uncopied
> (collect.c:580)
> ==19699==    by 0x4FC2976: run_gc (orchestrate.c:328)
> ==19699==    by 0x4FC320D: MVM_gc_enter_from_allocator (orchestrate.c:438)
> ==19699==    by 0x4FC3627: MVM_gc_allocate_nursery (allocation.c:32)
> ==19699==    by 0x4FC39ED: MVM_gc_allocate_frame (allocation.c:99)
> ==19699==    by 0x4FA749F: MVM_frame_force_to_heap (frame.c:657)
> ==19699==    by 0x4FA8D4C: MVM_frame_takeclosure (frame.c:1051)
> ==19699==    by 0xEA66105: ???
> ==19699==    by 0x50342B8: MVM_jit_enter_code (compile.c:136)
> ==19699==    by 0x4F938F0: MVM_interp_run (interp.c:5456)
> ==19699==
>     not ok 5 - decoding "Abcd"
>
> Which is suggestive of some kind of memory corruption (seemingly due to
> over-sharing or a premature free) inside of the argument capture. Still
> trying to figure out exactly what leads to this.
>
>

Reply via email to