GC walks into thread interp, examples/threads/chameneos.pir #880

Closed
leto opened this Issue Dec 11, 2012 · 3 comments

Comments

Projects
None yet
2 participants
@leto
Owner

leto commented Dec 11, 2012

$ parrot examples/threads/chameneos.pir
going to sleep
Bus error: 10 (core dumped)

Same with -DTHREAD_DEBUG, fixed with -G --no-gc

The fun part of this is that the backtrace is not the same each time I run this. Here are two different backraces:

Backtrace #1:

#0  0x000000010d584fc8 in Parrot_pcc_invoke_from_sig_object (interp=0x7ff142c03bf0, sub_obj=0x7ff1479ec838, call_object=0x7ff1479ec4f0) at pcc.c:339
339         Interp_core_SET(interp, old_core);
(gdb) bt
#0  0x000000010d584fc8 in Parrot_pcc_invoke_from_sig_object (interp=0x7ff142c03bf0, sub_obj=0x7ff1479ec838, call_object=0x7ff1479ec4f0) at pcc.c:339
#1  0x000000010d5649a0 in Parrot_ext_call (interp=0x7ff142c03bf0, sub_pmc=0x7ff1479ec838, signature=0x10d77b8f8 "P->") at extend.c:158
#2  0x000000010d71a4ab in Parrot_Task_invoke (interp=0x7ff142c03bf0, _self=0x7ff1490479f0, next=0x0) at task.c:168
#3  0x000000010d584f63 in Parrot_pcc_invoke_from_sig_object (interp=0x7ff142c03bf0, sub_obj=0x7ff1490479f0, call_object=0x7ff1479ec590) at pcc.c:330
#4  0x000000010d5649a0 in Parrot_ext_call (interp=0x7ff142c03bf0, sub_pmc=0x7ff1490479f0, signature=0x10d776edc "->") at extend.c:158
#5  0x000000010d5cad13 in Parrot_cx_next_task (interp=0x7ff142c03bf0, scheduler=0x7ff1430cd530) at scheduler.c:231
#6  0x000000010d5ca9d2 in Parrot_cx_outer_runloop (interp=0x7ff142c03bf0) at scheduler.c:149
#7  0x000000010d5ca6ff in Parrot_cx_begin_execution (interp=0x7ff142c03bf0, main=0x7ff143812a78, argv=0x7ff1430cd7d8) at scheduler.c:109
#8  0x000000010d5de31d in Parrot_pf_execute_bytecode_program (interp=0x7ff142c03bf0, pbc=0x7ff143813428, args=0x7ff1430cd7d8) at api.c:2829
#9  0x000000010d55af5a in Parrot_api_run_bytecode (interp_pmc=0x7ff1430c3bd8, pbc=0x7ff143813428, args=0x7ff1430cd7d8) at bytecode.c:161
#10 0x000000010d4eb86e in main (argc=2, argv=0x7fff527152f8) at main.c:172

Backtrace #2:

(gdb) bt
#0  0x00007fff8a7c1cef in cpu_number ()
#1  0x00007fff8a7fb7c5 in szone_malloc_should_clear ()
#2  0x00007fff8a7ee183 in malloc_zone_malloc ()
#3  0x00007fff8a7eebd7 in malloc ()
#4  0x000000010132434a in Parrot_PMCList_push_pmc_orig (interp=0x7fbef3c03bf0, _self=0x7fbef40cd5a8, value=0x7fbefe2d8870) at pmclist.c:515
#5  0x0000000101322985 in Parrot_PMCList_push_pmc (interp=0x7fbef3c03bf0, _self=0x7fbef40cd5a8, value=0x7fbefe2d8870) at pmclist.c:237
#6  0x00000001013480d3 in Parrot_Scheduler_push_pmc_orig (interp=0x7fbef3c03bf0, _self=0x7fbef40cd530, task=0x7fbefe2d8870) at scheduler.c:299
#7  0x0000000101346415 in Parrot_Scheduler_push_pmc (interp=0x7fbef3c03bf0, _self=0x7fbef40cd530, task=0x7fbefe2d8870) at scheduler.c:139
#8  0x00000001012083f8 in Parrot_cx_preempt_task (interp=0x7fbef3c03bf0, scheduler=0x7fbef40cd530, next=0x7fbef40fef58) at scheduler.c:375
#9  0x0000000101186417 in Parrot_pass (cur_opcode=0x7fbef40fef50, interp=0x7fbef3c03bf0) at core_ops.c:24537
#10 0x00000001011ffe4a in runops_fast_core (interp=0x7fbef3c03bf0, runcore_unused=0x7fbef3c0e980, pc=0x7fbef40fef50) at cores.c:499
#11 0x00000001011ff28a in runops_int (interp=0x7fbef3c03bf0, offset=555) at main.c:220
#12 0x00000001011cb3be in runops (interp=0x7fbef3c03bf0, offs=555) at ops.c:123
#13 0x00000001011c1fc4 in Parrot_pcc_invoke_from_sig_object (interp=0x7fbef3c03bf0, sub_obj=0x7fbef9a23678, call_object=0x7fbef9a23330) at pcc.c:338
#14 0x00000001011a19a0 in Parrot_ext_call (interp=0x7fbef3c03bf0, sub_pmc=0x7fbef9a23678, signature=0x1013b88f8 "P->") at extend.c:158
#15 0x00000001013574ab in Parrot_Task_invoke (interp=0x7fbef3c03bf0, _self=0x7fbefe2d8870, next=0x0) at task.c:168
#16 0x00000001011c1f63 in Parrot_pcc_invoke_from_sig_object (interp=0x7fbef3c03bf0, sub_obj=0x7fbefe2d8870, call_object=0x7fbef9a233d0) at pcc.c:330
#17 0x00000001011a19a0 in Parrot_ext_call (interp=0x7fbef3c03bf0, sub_pmc=0x7fbefe2d8870, signature=0x1013b3edc "->") at extend.c:158
#18 0x0000000101207d13 in Parrot_cx_next_task (interp=0x7fbef3c03bf0, scheduler=0x7fbef40cd530) at scheduler.c:231
#19 0x00000001012079d2 in Parrot_cx_outer_runloop (interp=0x7fbef3c03bf0) at scheduler.c:149
#20 0x00000001012076ff in Parrot_cx_begin_execution (interp=0x7fbef3c03bf0, main=0x7fbef40e1478, argv=0x7fbef40cd7d8) at scheduler.c:109
#21 0x000000010121b31d in Parrot_pf_execute_bytecode_program (interp=0x7fbef3c03bf0, pbc=0x7fbef40e1e28, args=0x7fbef40cd7d8) at api.c:2829
#22 0x0000000101197f5a in Parrot_api_run_bytecode (interp_pmc=0x7fbef40c3bd8, pbc=0x7fbef40e1e28, args=0x7fbef40cd7d8) at bytecode.c:161
#23 0x000000010112986e in main (argc=2, argv=0x7fff5ead72f8) at main.c:172
$ git rev-parse HEAD
48a2a418b9a144d5d164ef4c97a185d2a791b12a

Can anybody else reproduce this?

@ghost ghost assigned rurban Dec 12, 2012

@rurban

This comment has been minimized.

Show comment Hide comment
@rurban

rurban Dec 12, 2012

Member

Yes, I have it in a strange location in my debugger. Bus error 10 (ECX_BAD_ACCESS) looks interesting.
I got it in Parrot_gc_mark_PMC_alive_fun() at the first ASSERT line, but both interp and obj look valid.

Member

rurban commented Dec 12, 2012

Yes, I have it in a strange location in my debugger. Bus error 10 (ECX_BAD_ACCESS) looks interesting.
I got it in Parrot_gc_mark_PMC_alive_fun() at the first ASSERT line, but both interp and obj look valid.

@rurban

This comment has been minimized.

Show comment Hide comment
@rurban

rurban Dec 14, 2012

Member

With -DTHREAD_DEBUG I got an better error:

$ lldb ./parrot examples/threads/chameneos.pir 
Current executable set to './parrot' (x86_64).
(lldb) r
Process 56388 launched: '/usr/src/parrot/parrot-git/parrot' (x86_64)
going to sleep
src/pmc/fixedpmcarray.c:407: failed assertion '(data[i])->orig_interp == (interp)'
Backtrace - Obtained 15 stack frames (max trace depth is 32).
0   libparrot.dylib                     0x0000000100078b6f Parrot_print_backtrace + 47
1   libparrot.dylib                     0x0000000100078b3a Parrot_confess + 138
2   libparrot.dylib                     0x000000010018eb48 Parrot_FixedPMCArray_mark + 248
3   libparrot.dylib                     0x0000000100087437 gc_gms_process_work_list + 327
4   libparrot.dylib                     0x0000000100086a54 gc_gms_mark_and_sweep + 628
5   libparrot.dylib                     0x00000001000888e8 gc_gms_allocate_pmc_header + 168
6   libparrot.dylib                     0x000000010007e923 Parrot_gc_new_pmc_header + 83
7   libparrot.dylib                     0x00000001000c5ea6 get_new_pmc_header + 422
8   libparrot.dylib                     0x00000001000c5661 Parrot_pmc_new + 273
9   libparrot.dylib                     0x0000000100096a9a Parrot_pcc_invoke_from_sig_object + 138
10  libparrot.dylib                     0x0000000100079718 Parrot_ext_call + 392
11  libparrot.dylib                     0x00000001000cf4cd Parrot_cx_next_task + 317
12  libparrot.dylib                     0x00000001000d1354 Parrot_thread_outer_runloop + 148
13  libsystem_c.dylib                   0x00007fff96bc5742 _pthread_start + 327
14  libsystem_c.dylib                   0x00007fff96bb2181 thread_start + 13
Attempting to get PIR backtrace.  No guarantees.  Here goes...
current instr.: 'sem_wait_core' pc 554 (examples/threads/chameneos.pir:240)

...

Process 56388 stopped
* thread #2: tid = 0x2103, 0x00007fff97846212 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
    frame #0: 0x00007fff97846212 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill + 10:
-> 0x7fff97846212:  jae    0x7fff97846219            ; __pthread_kill + 17
   0x7fff97846214:  jmpq   0x7fff978474d4            ; cerror_nocancel
   0x7fff97846219:  ret    
   0x7fff9784621a:  nop    
Member

rurban commented Dec 14, 2012

With -DTHREAD_DEBUG I got an better error:

$ lldb ./parrot examples/threads/chameneos.pir 
Current executable set to './parrot' (x86_64).
(lldb) r
Process 56388 launched: '/usr/src/parrot/parrot-git/parrot' (x86_64)
going to sleep
src/pmc/fixedpmcarray.c:407: failed assertion '(data[i])->orig_interp == (interp)'
Backtrace - Obtained 15 stack frames (max trace depth is 32).
0   libparrot.dylib                     0x0000000100078b6f Parrot_print_backtrace + 47
1   libparrot.dylib                     0x0000000100078b3a Parrot_confess + 138
2   libparrot.dylib                     0x000000010018eb48 Parrot_FixedPMCArray_mark + 248
3   libparrot.dylib                     0x0000000100087437 gc_gms_process_work_list + 327
4   libparrot.dylib                     0x0000000100086a54 gc_gms_mark_and_sweep + 628
5   libparrot.dylib                     0x00000001000888e8 gc_gms_allocate_pmc_header + 168
6   libparrot.dylib                     0x000000010007e923 Parrot_gc_new_pmc_header + 83
7   libparrot.dylib                     0x00000001000c5ea6 get_new_pmc_header + 422
8   libparrot.dylib                     0x00000001000c5661 Parrot_pmc_new + 273
9   libparrot.dylib                     0x0000000100096a9a Parrot_pcc_invoke_from_sig_object + 138
10  libparrot.dylib                     0x0000000100079718 Parrot_ext_call + 392
11  libparrot.dylib                     0x00000001000cf4cd Parrot_cx_next_task + 317
12  libparrot.dylib                     0x00000001000d1354 Parrot_thread_outer_runloop + 148
13  libsystem_c.dylib                   0x00007fff96bc5742 _pthread_start + 327
14  libsystem_c.dylib                   0x00007fff96bb2181 thread_start + 13
Attempting to get PIR backtrace.  No guarantees.  Here goes...
current instr.: 'sem_wait_core' pc 554 (examples/threads/chameneos.pir:240)

...

Process 56388 stopped
* thread #2: tid = 0x2103, 0x00007fff97846212 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
    frame #0: 0x00007fff97846212 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill + 10:
-> 0x7fff97846212:  jae    0x7fff97846219            ; __pthread_kill + 17
   0x7fff97846214:  jmpq   0x7fff978474d4            ; cerror_nocancel
   0x7fff97846219:  ret    
   0x7fff9784621a:  nop    

rurban pushed a commit that referenced this issue Dec 16, 2012

Reini Urban
Undo GC work_list check. This may not happen
Rather fix the wrong paren_interp. See also GH #880

rurban pushed a commit that referenced this issue Dec 18, 2012

Reini Urban
[GH #880/#875] Try to fix some GC thread bugs
Do not ascent into parent_interpreter with a threaded interp. (No influence)
Do not mark PMCs when threaded interp is different to the current interp
(Parrot_gc_mark_PMC_alive)

rurban pushed a commit that referenced this issue Jan 4, 2013

Reini Urban
[GH #880/#875] Try to fix some GC thread bugs
Do not ascent into parent_interpreter with a threaded interp. (No influence)
Do not mark PMCs when threaded interp is different to the current interp
(Parrot_gc_mark_PMC_alive)

rurban pushed a commit that referenced this issue Jan 4, 2013

rurban pushed a commit that referenced this issue Jan 5, 2013

Reini Urban
[GH #880/#875] Try to fix some GC thread bugs
Do not ascent into parent_interpreter with a threaded interp. (No influence)
Do not mark PMCs when threaded interp is different to the current interp
(Parrot_gc_mark_PMC_alive)

rurban pushed a commit that referenced this issue Jan 5, 2013

rurban pushed a commit that referenced this issue Jan 11, 2013

rurban pushed a commit that referenced this issue Jan 11, 2013

Reini Urban
[GH #880/#875] Try to fix some GC thread bugs
Do not ascent into parent_interpreter with a threaded interp. (No influence)
Do not mark PMCs when threaded interp is different to the current interp
(Parrot_gc_mark_PMC_alive)

rurban pushed a commit that referenced this issue Jan 11, 2013

rurban pushed a commit that referenced this issue Jan 11, 2013

Reini Urban
[GH #880/#875] Apparently fixed the GC thread bugs
Also block the sweep phase from proxied interps. Previously only the mark.

rurban pushed a commit that referenced this issue Jan 12, 2013

Reini Urban
[GH #880] Fixed 1st threads test, todo only with THREAD_DEBUG
Run PARROT_GC_VALIDATE code only with THREAD_DEBUG.
It is not thread-safe on darwin.

@rurban rurban added To-verify and removed Bug labels Mar 11, 2014

@rurban

This comment has been minimized.

Show comment Hide comment
@rurban

rurban Jul 1, 2014

Member

Fixed with cb5beee and c13abd1

THREAD_DEBUG is not safe to use with darwin.

Member

rurban commented Jul 1, 2014

Fixed with cb5beee and c13abd1

THREAD_DEBUG is not safe to use with darwin.

@rurban rurban closed this Jul 1, 2014

rurban pushed a commit that referenced this issue Dec 8, 2014

Reini Urban
[GH #880/#875] Apparently fixed the GC thread bugs
Also block the sweep phase from proxied interps. Previously only the mark.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment