https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112010-11-01T02:47:40ZRuby Issue Tracking SystemBackport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=139782010-11-01T02:47:40Znanodeath (Max Aller)nanodeath@gmail.com
<ul></ul><p>=begin<br>
Note: this also happens with ruby-1.9.2-p0. The provided program doesn't terminate at all using ruby-1.8.7-p302.<br>
=end</p> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=141772010-11-16T19:22:50Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>=begin<br>
I can't reproduce this.<br>
Can you show gdb backtrace?</p>
<p>ruby 1.9.3dev (2010-11-09 trunk 29733) [i686-linux]<br>
1277:12: warning: assigned but unused variable - job<br>
/home/naruse/local/ruby/lib/ruby/1.9.1/thread.rb:71:in <code>sleep': deadlock detected (fatal) from /home/naruse/local/ruby/lib/ruby/1.9.1/thread.rb:71:in </code>wait'<br>
from /home/naruse/local/ruby/lib/ruby/1.9.1/monitor.rb:100:in <code>wait' from /home/naruse/local/ruby/lib/ruby/1.9.1/monitor.rb:121:in </code>wait_until'<br>
from 1277:49:in <code>block in <main>' from /home/naruse/local/ruby/lib/ruby/1.9.1/monitor.rb:201:in </code>mon_synchronize'<br>
from 1277:48:in `'</p>
<p>=end</p> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=141782010-11-16T19:52:24Znagachika (Tomoyuki Chikanaga)nagachika00@gmail.com
<ul></ul><p>=begin<br>
Hi<br>
I can reproduce similar SEGV under gdb with "ruby 1.9.3dev (2010-11-16 trunk 29789) [i686-linux]"</p>
<p>Program received signal SIGSEGV, Segmentation fault.<br>
[Switching to Thread -1222669392 (LWP 14762)]<br>
0x0813df46 in vm_call0 (th=0x9384238, recv=153972280, id=2512, argc=1,<br>
argv=0xb71f8948, me=0x92e8a68) at vm_eval.c:75<br>
75 vm_push_frame(th, 0, VM_FRAME_MAGIC_CFUNC,<br>
(gdb) where<br>
#0 0x0813df46 in vm_call0 (th=0x9384238, recv=153972280, id=2512, argc=1,<br>
argv=0xb71f8948, me=0x92e8a68) at vm_eval.c:75<br>
#1 0x0813e711 in check_funcall (recv=153972280, mid=2512, argc=1,<br>
argv=0xb71f8948) at vm_eval.c:290<br>
#2 0x0813e73e in rb_check_funcall (recv=153972280, mid=2512, argc=1,<br>
argv=0xb71f8948) at vm_eval.c:296<br>
#3 0x08059e05 in make_exception (argc=2, argv=0xb71f8944, isstr=1)<br>
at eval.c:552<br>
#4 0x08059ebb in rb_make_exception (argc=2, argv=0xb71f8944) at eval.c:574<br>
#5 0x081484e8 in rb_threadptr_raise (th=0x92a7568, argc=2, argv=0xb71f8944)<br>
at thread.c:1350<br>
<a class="issue tracker-1 status-5 priority-4 priority-default closed behind-schedule" title="Bug: sprintf() of %f on Windows(MSVCRT) (Closed)" href="https://bugs.ruby-lang.org/issues/6">#6</a> 0x0814c31a in rb_check_deadlock (vm=0x92a72e0) at thread.c:4465<br>
#7 0x08147286 in thread_start_func_2 (th=0x9384238, stack_start=0xb71f8a78)<br>
at thread.c:516<br>
#8 0x08146356 in thread_start_func_1 (th_ptr=0x9384238)<br>
at thread_pthread.c:361<br>
#9 0x00666dd8 in start_thread () from /lib/tls/libpthread.so.0<br>
#10 0x00f83d1a in clone () from /lib/tls/libc.so.6</p>
<p>th->cfp seems pointed invalid address</p>
<p>(gdb) p reg_cfp->sp<br>
Cannot access memory at address 0xb7278fe0<br>
(gdb) p reg_cfp<br>
$9 = (rb_control_frame_t *) 0xb7278fdc<br>
(gdb) p *reg_cfp<br>
Cannot access memory at address 0xb7278fdc<br>
(gdb) p th->cfp<br>
$10 = (rb_control_frame_t *) 0xb7278fdc</p>
<p>=end</p> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=141822010-11-17T11:33:35Znagachika (Tomoyuki Chikanaga)nagachika00@gmail.com
<ul></ul><p>=begin<br>
I think the following patch fixes this situation.<br>
Max, could you try this patch?</p>
<p>BTW I'm not too confident in this patch. Please review it.</p>
<a name="Index-threadc"></a>
<h1 >Index: thread.c<a href="#Index-threadc" class="wiki-anchor">¶</a></h1>
<p>--- thread.c (revision 29809)<br>
+++ thread.c (working copy)<br>
@@ -507,13 +507,14 @@<br>
join_th = join_th->join_list_next;<br>
}</p>
<ul>
<li>
<pre><code> thread_unlock_all_locking_mutexes(th);
</code></pre>
</li>
<li>
<pre><code> if (th != main_th) rb_check_deadlock(th->vm);
</code></pre>
</li>
<li>
<pre><code> if (!th->root_fiber) {
rb_thread_recycle_stack_release(th->stack);
th->stack = 0;
}
</code></pre>
}</li>
</ul>
<ul>
<li>thread_unlock_all_locking_mutexes(th);</li>
<li>if (th != main_th) rb_check_deadlock(th->vm);<br>
if (th->vm->main_thread == th) {<br>
ruby_cleanup(state);<br>
}</li>
</ul>
<p>=end</p> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=148332010-12-24T09:14:10Znagachika (Tomoyuki Chikanaga)nagachika00@gmail.com
<ul></ul><p>=begin<br>
Hi,<br>
I can still reproduce this segv on trunk(r30329) and also on 1.9.2-HEAD(r30326).<br>
Please check the previous patch, thanks.<br>
=end</p> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=152982011-01-18T12:10:09Znanodeath (Max Aller)nanodeath@gmail.com
<ul></ul><p>=begin<br>
Hit this on Ruby 1.9.3dev (2011-01-18 trunk 30590) [i686-linux] again. Tried applying the above patch (had to improvise regarding line numbers a little) but didn't seem to have any effect. The first two times I ran my script again it segfaulted as described in the original ticket, but the third time it hung with "*** glibc detected *** ruby: corrupted double-linked list: 0x0973f110 ***" immediately after the "C level backtrace information" header and I had to kill -9 it.<br>
=end</p> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=152992011-01-18T13:11:17Znanodeath (Max Aller)nanodeath@gmail.com
<ul><li><strong>File</strong> <a href="/attachments/1424">proof_of_segfault_small.rb</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1424/proof_of_segfault_small.rb">proof_of_segfault_small.rb</a> added</li></ul><p>=begin<br>
Good news, I have managed to greatly reduce the failing code, which will hopefully make it easier to figure out. It's attached.<br>
=end</p> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=153432011-01-19T22:37:27Znagachika (Tomoyuki Chikanaga)nagachika00@gmail.com
<ul></ul><p>=begin<br>
Hi,<br>
The reduced sample code saves time to examine. Thank you :)<br>
I also can reproduce segv in my Linux environment with ruby 1.9.3dev (2011-01-18 trunk 30590) [i686-linux], for both 'proof_og_segfault.rb' and 'proof_of_segfault_small.rb'.<br>
But my previous patch seems effective in my environment.<br>
Hmm, there may be another potential problems. I'll check with valgrind later.<br>
=end</p> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=153782011-01-21T00:04:50Znagachika (Tomoyuki Chikanaga)nagachika00@gmail.com
<ul></ul><p>=begin<br>
Hi,<br>
I've checked again with valgrind and get no extra problem report.<br>
Sorry I can't hel</p>
<p>I have noticed that according to 'proof_of_segfault_output', your ruby should be build with --enable-shared configuration.<br>
And if you retry with my patch like below, it could be dynamically linked with installed ~/.rvm/rubies/ruby-head/lib/libruby.so.1.9</p>
<p>(in building directory. after apply patch)<br>
% make<br>
% ./ruby proof_of_segfault.rb</p>
<p>If so, how about command like like below?</p>
<p>% LD_LIBRARY_PATH=<building_directory> ./ruby proof_of_segfault.rb<br>
=end</p> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=154752011-01-24T03:30:15Znanodeath (Max Aller)nanodeath@gmail.com
<ul></ul><p>=begin<br>
Tomoyuki, I suspect you were right regarding the linking situation -- so I applied your patch to my .rvm/repos/ruby-head path and ran rvm --static install ruby-head (which, interestingly, does not perform a <code>git pull</code>, so I did that manually; it just copies from repos/ to src/ and configures/builds/installs), and...presto, no more segfault! Get the deadlock detected error instead, which I think is the desired behavior. I even raised/lowered the worker count, still deadlocks.</p>
<p>To be thorough, I also tried running my sample with stock ruby-head, and it did still have the bug, so I think your patch is, at the very least, a functional solution.</p>
<p>Nice work.<br>
=end</p> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=155342011-01-27T01:26:08Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>=begin<br>
Hi,</p>
<p>2010/11/17 Tomoyuki Chikanaga <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a>:</p>
<blockquote>
<p>BTW I'm not too confident in this patch. Please review it.</p>
<a name="Index-threadc"></a>
<h1 >Index: thread.c<a href="#Index-threadc" class="wiki-anchor">¶</a></h1>
<p>--- thread.c (revision 29809)<br>
+++ thread.c (working copy)<br>
@@ -507,13 +507,14 @@<br>
join_th = join_th->join_list_next;<br>
}</p>
<ul>
<li> thread_unlock_all_locking_mutexes(th);</li>
<li> if (th != main_th) rb_check_deadlock(th->vm);</li>
<li>
</ul>
<p> if (!th->root_fiber) {<br>
rb_thread_recycle_stack_release(th->stack);<br>
th->stack = 0;<br>
}<br>
}</p>
<ul>
<li> thread_unlock_all_locking_mutexes(th);</li>
<li> if (th != main_th) rb_check_deadlock(th->vm);<br>
if (th->vm->main_thread == th) {<br>
ruby_cleanup(state);<br>
}</li>
</ul>
</blockquote>
<p>Looks good. Nice work!</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a></p>
<p>=end</p> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=155392011-01-27T11:19:35Znagachika (Tomoyuki Chikanaga)nagachika00@gmail.com
<ul></ul><p>=begin<br>
Hi,</p>
<p>Max san, thank you for checking my patch again. I'm relieved to hear that it works fine.</p>
<p>Endoh san, thank you for reviewing.<br>
I'll check in the patch later if there is no opposition.<br>
=end</p> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=156262011-01-31T21:47:06Znagachika (Tomoyuki Chikanaga)nagachika00@gmail.com
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>=begin<br>
This issue was solved with changeset r30743.<br>
Max, thank you for reporting this issue.<br>
Your contribution to Ruby is greatly appreciated.<br>
May Ruby be with you.</p>
<hr>
<ul>
<li>thread.c (thread_start_func_2): check deadlock condition before<br>
release thread stack. fix memory violation when deadlock detected.<br>
reported by Max Aller. [Bug <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Backport: Segfault with combination of threads and condition variables (Closed)" href="https://bugs.ruby-lang.org/issues/4009">#4009</a>] <a href="/issues/4009">[ruby-core:32982]</a><br>
=end</li>
</ul> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=156272011-01-31T22:04:04Znagachika (Tomoyuki Chikanaga)nagachika00@gmail.com
<ul><li><strong>Status</strong> changed from <i>Closed</i> to <i>Assigned</i></li><li><strong>Assignee</strong> set to <i>yugui (Yuki Sonoda)</i></li></ul><p>=begin<br>
Please backport r30743 to 1.9.2<br>
=end</p> Backport193 - Backport #4009: Segfault with combination of threads and condition variableshttps://bugs.ruby-lang.org/issues/4009?journal_id=206202011-09-06T21:36:46Znagachika (Tomoyuki Chikanaga)nagachika00@gmail.com
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Closed</i></li></ul><p>This issue was solved with changeset r30743.<br>
Max, thank you for reporting this issue.<br>
Your contribution to Ruby is greatly appreciated.<br>
May Ruby be with you.</p>
<hr>
<ul>
<li>thread.c (thread_start_func_2): check deadlock condition before<br>
release thread stack. fix memory violation when deadlock detected.<br>
reported by Max Aller. [Bug <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Backport: Segfault with combination of threads and condition variables (Closed)" href="https://bugs.ruby-lang.org/issues/4009">#4009</a>] <a href="/issues/4009">[ruby-core:32982]</a></li>
</ul>