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>