debugging a race in the web server

[avoine]

I was running some benchmark on fiber's web server and found that sometimes channels spin infinitly.

With #:parallel? to #t and 2 concurent requests, it finish 10-15 requests and then stop responding.
I can see one thread spinning infinitly on scm_atomic_compare_and_swap_scm.

WhenI set #:parallel? to #f or with more then 2 concurent requests it finish all the requests
except one or two and spin infinitly.

Could it be that for some reason all put-operation are finished and there is one get-operation left or vice-versa? How would you debug that?

Here's the GDB backtrace:

btw, GDB's guile extension is not working with guile 2.1.5 because of the changes in libguile/ports.c.
But you probably knew that already ;-)

#0  scm_atomic_compare_and_swap_scm (loc=0x5555557b95d8, expected=0x7ffff18faba0, desired=0x304) at ../libguile/atomics-internal.h:74
#1  0x00007ffff7aab337 in scm_i_async_pop (t=0x5555557b9540) at async.c:125
#2  0x00007ffff7b60d0d in vm_regular_engine (thread=0x5555557b9540, vp=0x555555c6dbd0, registers=0x7ffff18fba30, resume=1) at vm-engine.c:3887
#3  0x00007ffff7b7258a in scm_call_n (proc=0x555555c98ca0, argv=0x0, nargs=0) at vm.c:1250
#4  0x00007ffff7abed02 in scm_call_0 (proc=0x555555c98ca0) at eval.c:475
#5  0x00007ffff7aab920 in scm_call_with_unblocked_asyncs (proc=0x555555c98ca0) at async.c:400
#6  0x00007ffff7ad767c in scm_apply_subr (sp=0x7ffff10fdf70, nslots=2) at gsubr.c:305
#7  0x00007ffff7b56041 in vm_regular_engine (thread=0x5555557b9540, vp=0x555555c6dbd0, registers=0x7ffff18fca00, resume=0) at vm-engine.c:778
#8  0x00007ffff7b7258a in scm_call_n (proc=0x555555c82e40, argv=0x0, nargs=0) at vm.c:1250
#9  0x00007ffff7abed02 in scm_call_0 (proc=0x555555c82e40) at eval.c:475
#10 0x00007ffff7b4eeda in really_launch (d=0x555555c94b60) at threads.c:783
#11 0x00007ffff7ab809c in c_body (d=0x7ffff18fde00) at continuations.c:425
#12 0x00007ffff7b514a8 in apply_catch_closure (clo=0x555555c98dc0, args=0x304) at throw.c:307
#13 0x00007ffff7b285f4 in apply_1 (smob=0x555555c98dc0, a=0x304) at smob.c:141
#14 0x00007ffff7ad76a4 in scm_apply_subr (sp=0x7ffff10fdfc0, nslots=3) at gsubr.c:307
#15 0x00007ffff7b56041 in vm_regular_engine (thread=0x5555557b9540, vp=0x555555c6dbd0, registers=0x7ffff18fda90, resume=0) at vm-engine.c:778
#16 0x00007ffff7b7258a in scm_call_n (proc=0x555555c98dc0, argv=0x0, nargs=0) at vm.c:1250
#17 0x00007ffff7abed02 in scm_call_0 (proc=0x555555c98dc0) at eval.c:475
#18 0x00007ffff7b50f08 in catch (tag=0x404, thunk=0x555555c98dc0, handler=0x555555c98da0, pre_unwind_handler=0x555555c98d80) at throw.c:138
#19 0x00007ffff7b51352 in scm_catch_with_pre_unwind_handler (key=0x404, thunk=0x555555c98dc0, handler=0x555555c98da0, pre_unwind_handler=0x555555c98d80) at throw.c:252
#20 0x00007ffff7b51580 in scm_c_catch (tag=0x404, body=0x7ffff7ab8074 , body_data=0x7ffff18fde00, handler=0x7ffff7ab80ae , handler_data=0x7ffff18fde00, 
    pre_unwind_handler=0x7ffff7ab8108 , pre_unwind_handler_data=0x55555583f040) at throw.c:375
#21 0x00007ffff7ab7eeb in scm_i_with_continuation_barrier (body=0x7ffff7ab8074 , body_data=0x7ffff18fde00, handler=0x7ffff7ab80ae , handler_data=0x7ffff18fde00, 
    pre_unwind_handler=0x7ffff7ab8108 , pre_unwind_handler_data=0x55555583f040) at continuations.c:363
#22 0x00007ffff7ab81b4 in scm_c_with_continuation_barrier (func=0x7ffff7b4ee70 , data=0x555555c94b60) at continuations.c:459
#23 0x00007ffff7b4eb81 in with_guile (base=0x7ffff18fde70, data=0x7ffff18fdec0) at threads.c:650
#24 0x00007ffff7233952 in GC_call_with_stack_base () from /usr/lib/x86_64-linux-gnu/libgc.so.1
#25 0x00007ffff7b4ec6a in scm_i_with_guile (func=0x7ffff7b4ee70 , data=0x555555c94b60, dynamic_state=0x555555c77470) at threads.c:693
#26 0x00007ffff7b4ef26 in launch_thread (d=0x555555c94b60) at threads.c:792
#27 0x00007ffff78576ca in start_thread (arg=0x7ffff18fe700) at pthread_create.c:333
#28 0x00007ffff75910af in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

where (not sure how useful this is...)

(gdb) print expected
$2 = (SCM *) 0x7ffff18faba0
(gdb) x 0x7ffff18faba0
0x7ffff18faba0:	0x55c0e8c0

[wingo]

Hi @avoine, thanks for trying out Fibers :) Are you using Guile 2.1.6? It fixes some race-condition-related bugs. Let me know.