Project

General

Profile

Bug #10495

Attaching lldb to a program running `sleep` hangs the VM

Added by cesario (Franck Verrot) over 5 years ago. Updated 3 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
ruby 2.2.0dev (2014-10-19 trunk 48023) [x86_64-darwin13]
[ruby-core:66214]

Description

Here's the bit of Ruby code:

loop do
sleep 1
puts 1
end

Here's the lldb session:

`(lldb) attach 41619
Process 41619 stopped
(lldb) c
Process 41619 resuming
Process 41619 stopped

  • thread #1: tid = 0x75fd5, 0x00007fff89f56716 libsystem_kernel.dylib__psynch_cvwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00007fff89f56716 libsystem_kernel.dylibpsynch_cvwait + 10 libsystem_kernel.dylib`psynch_cvwait + 10: -> 0x7fff89f56716: jae 0x7fff89f56720 ; __psynch_cvwait + 20 0x7fff89f56718: movq %rax, %rdi 0x7fff89f5671b: jmpq 0x7fff89f53175 ; cerror_nocancel 0x7fff89f56720: ret (lldb) p (int)rb_eval_string("puts 1") (int) $0 = 8 (lldb) c Process 41619 resuming Process 41619 stopped
  • thread #1: tid = 0x75fd5, 0x00007fff89f56716 libsystem_kernel.dylib__psynch_cvwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00007fff89f56716 libsystem_kernel.dylibpsynch_cvwait + 10 libsystem_kernel.dylib`psynch_cvwait + 10: -> 0x7fff89f56716: jae 0x7fff89f56720 ; __psynch_cvwait + 20 0x7fff89f56718: movq %rax, %rdi 0x7fff89f5671b: jmpq 0x7fff89f53175 ; cerror_nocancel 0x7fff89f56720: ret (lldb) bt
  • thread #1: tid = 0x75fd5, 0x00007fff89f56716 libsystem_kernel.dylib`__psynch_cvwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    • frame #0: 0x00007fff89f56716 libsystem_kernel.dylib__psynch_cvwait + 10 frame #1: 0x00007fff962c0c3b libsystem_pthread.dylib_pthread_cond_wait + 727 frame #2: 0x000000010a0d8f82 rubygvl_acquire_common + 146 frame #3: 0x000000010a0d1880 rubynative_sleep + 464 frame #4: 0x000000010a0d24dc rubysleep_timeval + 268 frame #5: 0x000000010a016cd4 rubyrb_f_sleep + 52 frame #6: 0x000000010a0ca02b rubyvm_call_cfunc + 987 frame #7: 0x000000010a0b31db rubyvm_exec_core + 10155 frame #8: 0x000000010a0c04af rubyvm_exec + 127 frame #9: 0x000000010a0c5a11 rubyloop_i + 49 frame #10: 0x0000000109f9b432 rubyrb_rescue2 + 274 frame #11: 0x000000010a0bef73 rubyrb_f_loop + 51 frame #12: 0x000000010a0ca02b rubyvm_call_cfunc + 987 frame #13: 0x000000010a0c9970 rubyvm_call_method + 848 frame #14: 0x000000010a0b3033 rubyvm_exec_core + 9731 frame #15: 0x000000010a0c04af rubyvm_exec + 127 frame #16: 0x000000010a0c1398 rubyrb_iseq_eval_main + 392 frame #17: 0x0000000109f9a8a4 rubyruby_exec_internal + 148 frame #18: 0x0000000109f9a7ce rubyruby_run_node + 78 frame #19: 0x0000000109f5c4ef rubymain + 79`

TL;DR : I'm asking Ruby to eval "puts 1". AFAICT, gvl_acquire_common that calls pthread's native_sleep/pthread_cond_wait never wakes up.

But, if I don't call puts (which would be, within lldb, equivalent to 'p (int)rb_eval_string("1")', the thread will continue running normally.

Please let me know if any info's missing.
Thanks in advance,
Franck

#1

Updated by naruse (Yui NARUSE) about 2 years ago

  • Target version deleted (2.2.0)

Updated by mame (Yusuke Endoh) 3 months ago

  • Status changed from Open to Closed

I tried the process on Ubuntu, but I couldn't reproduce the issue. Maybe it is already fixed? Tentatively closing. Let me know if you still see the issue.

AFAIK there is no committer that daily uses lldb for ruby. Contribution is welcome.

Also available in: Atom PDF