Koichi Sasada <ko1 / atdot.net> wrote:
> http://ci.rvm.jp/results/trunk@P895/1332973
> similar?

Ugh.  Now I'm not sure what is going on.  The fact the C
backtrace says queue_do_pop probably means there's a leftover
thread, probably from DRb; which is an old test bug and affects
a lot of the asserts CI.

Maybe r64782; but that issue is still confusing me.  It is
also needed for Thread::Light; but I'm also not sure why :x
(sorry, I do not have much computer time this month)

> On 2018/09/13 11:00, Eric Wong wrote:
> > Koichi Sasada <ko1 / atdot.net> wrote:
> > > any idea?
> > 
> > Maybe r64707, except spawn shouldn't call fork there
> > (only vfork).  Seems similar to [ruby-core:88774] and very rare
> > to hit.  Any other CI machines hit EINVAL on pthread_mutex_unlock?
> > 
> > I'm 99% sure r64707 fixes A bug, but I don't know if it fixes THIS bug...
> > 
> > Do you have ./configure log output?
> > 
> > > rsult : NG (r64706)
> > > detail: https://gist.github.com/6a8e880353fc1220cba65d38e247dd7b
> > 
> > >   @logfile="/home/ko1/ruby/logs/brlog.trunk.20180913-100644",
> > 
> > > http://ci.rvm.jp/results/trunk@P895/1313604
> > 
> > I can't find configure output in those.  Thanks.

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>