< :前の番号
^ :番号順リスト
> :次の番号
P :前の記事
N :次の記事
|<:スレッドの先頭
>|:次のスレッド
^ :返事先
_:自分への返事
>:同じ返事先を持つ記事（前）
<:同じ返事先を持つ記事（後）
---:分割してスレッド表示、再表示
| :分割して（縦）スレッド表示、再表示
~ :スレッドのフレーム消去
.:インデックス
..:インデックスのインデックス
hirura / gmail.com wrote:
> File gdb_trace_reproduced.txt added
> ruby -v changed from ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux] to ruby 2.6.0dev (2018-06-15 trunk 63671) [x86_64-linux]
Odd, it is stuck in rb_mutex_sleep based on your backtrace (from
Logger, it looks like); and you can reproduce it on recent trunk.
I'm trying to reproduce the bug, but I cannot. I will let it
run while I do other things...
I suspect the problem is a bug in our deadlock detection
(vm->sleeper (*))
In your code, you have a t0 dummy thread. Is it really needed?
Curious, how many CPU cores and what model do you have?
Can you reproduce it if you use taskset or schedtool to limit
it to a single core?
Do you have a different hardware to try on?
(*) I also wonder why vm->sleeper is volatile, it should not
need to be.
Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>