[bug #33996] 2.0.2: Crash related to ports and threads

[bug #33996] 2.0.2: Crash related to ports and threads

[Cedric Cellier]

URL:
  <http://savannah.gnu.org/bugs/?33996>

                 Summary: 2.0.2: Crash related to ports and threads
                 Project: Guile
            Submitted by: rixed
            Submitted on: ven. 12 août 2011 09:42:12 CEST
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

On a fresh guile 2.0.2 configured --with-threads, this simple programs:

---
(use-modules (ice-9 threads))

(define (forever f)
  (f)
  (forever f))

; Spawn a thread that performs some writes
(make-thread forever (lambda ()
                                           (display "write...\n")))

(forever (lambda () (display "new pipe...\n")))
---

... either segfault, leading to this stackframes :

Thread 2 (Thread 16262):
#0  0x00007f30eecc861e in __pthread_mutex_unlock_usercnt () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007f30f0238556 in scm_display (obj=0x1015da0, port=0xba9850) at
print.c:1327
#2  0x00007f30f0273c60 in vm_debug_engine (vm=0xba98e0, program=0x0,
argv=0xbac290, nargs=12181792) at vm-i-system.c:895
#3  0x00007f30f0273c70 in vm_debug_engine (vm=0xba98e0, program=0x0,
argv=0xbac218, nargs=12174400) at vm-i-system.c:892
#4  0x00007f30f01f7bf3 in scm_primitive_eval (exp=0xd88860) at eval.c:639
#5  0x00007f30f01f7c53 in scm_eval (exp=0xd88860, module_or_state=0xcb6090) at
eval.c:673
#6  0x00007f30f02442af in scm_shell (argc=3, argv=0x7fffcde3e608) at
script.c:402
#7  0x00007f30f0213cbf in invoke_main_func (body_data=<value optimized out>)
at init.c:336
#8  0x00007f30f01ee4ba in c_body (d=0x7fffcde3e440) at continuations.c:512
#9  0x00007f30f027d6cb in vm_regular_engine (vm=0xba98e0,
program=0x7f30f02a7072, argv=0xbac0a8, nargs=12239008) at vm-i-system.c:960
#10 0x00007f30f01f78c3 in scm_call_4 (proc=0xc7de40, arg1=<value optimized
out>, arg2=<value optimized out>, arg3=<value optimized out>, 
    arg4=<value optimized out>) at eval.c:506
#11 0x00007f30f01eeca3 in scm_i_with_continuation_barrier (body=0x7f30f01ee4b0
<c_body>, body_data=0x7fffcde3e440, handler=0x7f30f01ee880 <c_handler>, 
    handler_data=0x7fffcde3e440, pre_unwind_handler=<value optimized out>,
pre_unwind_handler_data=<value optimized out>) at continuations.c:450
#12 0x00007f30f01eed55 in scm_c_with_continuation_barrier (func=<value
optimized out>, data=<value optimized out>) at continuations.c:546
#13 0x00007f30f0265d05 in with_guile_trampoline (base=0x7fffcde3e4a0,
data=0x7fffcde3e4c0) at threads.c:854
#14 with_gc_active (base=0x7fffcde3e4a0, data=0x7fffcde3e4c0) at
threads.c:225
#15 with_guile_and_parent (base=0x7fffcde3e4a0, data=0x7fffcde3e4c0) at
threads.c:900
#16 0x00007f30eff50a05 in GC_call_with_stack_base () from /usr/lib/libgc.so.1
#17 0x00007f30f0265ea8 in scm_i_with_guile_and_parent (func=<value optimized
out>, data=<value optimized out>) at threads.c:915
#18 scm_with_guile (func=<value optimized out>, data=<value optimized out>) at
threads.c:921
#19 0x00007f30f0213dd5 in scm_boot_guile (argc=<value optimized out>,
argv=<value optimized out>, main_func=<value optimized out>, 
    closure=<value optimized out>) at init.c:319
#20 0x00000000004009c0 in main (argc=<value optimized out>, argv=<value
optimized out>) at guile.c:70

Thread 1 (Thread 16263):
#0  update_port_lf (ptr=0x7f30ee31f000 <Address 0x7f30ee31f000 out of bounds>,
size=888516242341, port=0xba9850) at ports.c:1069
#1  scm_lfwrite (ptr=0x7f30ee31f000 <Address 0x7f30ee31f000 out of bounds>,
size=888516242341, port=0xba9850) at ports.c:1428
#2  0x00007f30f0237c16 in display_string_using_iconv (str=0xfc0290,
narrow_p=1, len=9, port=0xba9850,
strategy=SCM_FAILED_CONVERSION_QUESTION_MARK)
    at print.c:950
#3  0x00007f30f0237d1c in display_string (str=0xfc0290, narrow_p=1, len=9,
port=0xba9850, strategy=<value optimized out>) at print.c:984
#4  0x00007f30f023967a in iprin1 (exp=0x1015e00, port=0xba9850, pstate=<value
optimized out>) at print.c:585
#5  0x00007f30f02398e2 in scm_prin1 (exp=0x1015e00, port=0xba9850, writingp=0)
at print.c:769
#6  0x00007f30f0238556 in scm_display (obj=0x1015e00, port=0xba9850) at
print.c:1327
#7  0x00007f30f0273c60 in vm_debug_engine (vm=0x1018f70, program=0x0,
argv=0x1052180, nargs=12181792) at vm-i-system.c:895
#8  0x00007f30f01f787e in scm_call_3 (proc=0xc7de40, arg1=<value optimized
out>, arg2=<value optimized out>, arg3=<value optimized out>) at eval.c:499
#9  0x00007f30f02664ad in really_launch (d=0x7fffcde3de50) at threads.c:973
#10 0x00007f30f01ee4ba in c_body (d=0x7f30ee31bde0) at continuations.c:512
#11 0x00007f30f0273ca0 in vm_debug_engine (vm=0x1018f70, program=0x10520a0,
argv=0x10520a8, nargs=1) at vm-i-system.c:960
#12 0x00007f30f01f78c3 in scm_call_4 (proc=0xc7de40, arg1=<value optimized
out>, arg2=<value optimized out>, arg3=<value optimized out>, 
    arg4=<value optimized out>) at eval.c:506
#13 0x00007f30f01eeca3 in scm_i_with_continuation_barrier (body=0x7f30f01ee4b0
<c_body>, body_data=0x7f30ee31bde0, handler=0x7f30f01ee880 <c_handler>, 
    handler_data=0x7f30ee31bde0, pre_unwind_handler=<value optimized out>,
pre_unwind_handler_data=<value optimized out>) at continuations.c:450
#14 0x00007f30f01eed55 in scm_c_with_continuation_barrier (func=<value
optimized out>, data=<value optimized out>) at continuations.c:546
#15 0x00007f30f0265d05 in with_guile_trampoline (base=0x7f30ee31be40,
data=0x7f30ee31be60) at threads.c:854
#16 with_gc_active (base=0x7f30ee31be40, data=0x7f30ee31be60) at
threads.c:225
#17 with_guile_and_parent (base=0x7f30ee31be40, data=0x7f30ee31be60) at
threads.c:900
#18 0x00007f30eff50a05 in GC_call_with_stack_base () from /usr/lib/libgc.so.1
#19 0x00007f30f026599e in scm_i_with_guile_and_parent (d=0x7fffcde3de50) at
threads.c:915
#20 launch_thread (d=0x7fffcde3de50) at threads.c:983
#21 0x00007f30eff55a5a in GC_inner_start_routine () from /usr/lib/libgc.so.1
#22 0x00007f30eff50a05 in GC_call_with_stack_base () from /usr/lib/libgc.so.1
#23 0x00007f30eecc4b40 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#24 0x00007f30eea0f36d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#25 0x0000000000000000 in ?? ()

... or throw an unexpected exception :

Backtrace:
In ice-9/boot-9.scm:
 170: 8 [catch #t #<catch-closure db3b00> ...]
In unknown file:
   ?: 7 [catch-closure]
In ice-9/boot-9.scm:
  62: 6 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 389: 5 [eval # #]
In ice-9/boot-9.scm:
2103: 4 [save-module-excursion #<procedure 1064180 at ice-9/boot-9.scm:3547:3
()>]
3554: 3 [#<procedure 1064180 at ice-9/boot-9.scm:3547:3 ()>]
In unknown file:
   ?: 2 [load-compiled/vm
"/home/rixed/.cache/guile/ccache/2.0-LE-8-2.0/home/rixed/crash.scm.go"]
In /home/rixed/crash.scm:
   6: 1 [forever #<procedure 1017be0 at /home/rixed/crash.scm:13:9 ()>]
In unknown file:
   ?: 0 [display "new pipe...
" #<undefined>]

ERROR: In procedure display:
ERROR: In procedure fport_write: Bad address





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?33996>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/

Re: [bug #33996] 2.0.2: Crash related to ports and threads

[Andy Wingo]

Hi Cedric,

On Fri 12 Aug 2011 09:42, Cedric Cellier <INVALID.NOREPLY@gnu.org> writes:

> (use-modules (ice-9 threads))
>
> (define (forever f)
>   (f)
>   (forever f))
>
> ; Spawn a thread that performs some writes
> (make-thread forever (lambda ()
>                        (display "write...\n")))
>
> (forever (lambda () (display "new pipe...\n")))

Oh dear, this is a nasty one.  The issue is that Guile's ports are not
threadsafe.  I hadn't thought about this one...

I am adding guile-devel to the Cc for input.  Any fix to this will be
pretty big, I think.  I think that the right fix here is probably what
Glibc does; see `info libc "Streams and Threads"` for the full details.

Basically they add a lock to each FILE*, which is probably what we
should do with our ports.  We could investigate Java's biased locking,
if that's useful.

Andy
-- 
http://wingolog.org/

Re: [bug #33996] 2.0.2: Crash related to ports and threads

[Ludovic Courtès]

Hi!

Andy Wingo <wingo@pobox.com> skribis:

> Oh dear, this is a nasty one.  The issue is that Guile's ports are not
> threadsafe.  I hadn't thought about this one...
>
> I am adding guile-devel to the Cc for input.  Any fix to this will be
> pretty big, I think.  I think that the right fix here is probably what
> Glibc does; see `info libc "Streams and Threads"` for the full details.

Indeed, it would probably need per-port mutexes, making I/O primitives
thread-safe by default, and perhaps providing unlocked variants like
libc does.

Putting our fat mutexes on a diet seems like a prerequisite...

Thanks,
Ludo’.