From owner-freebsd-current@freebsd.org Sun Jun 25 02:04:47 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEFBAD865B8 for ; Sun, 25 Jun 2017 02:04:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 52E557FF21 for ; Sun, 25 Jun 2017 02:04:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5P24gM8084073 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 05:04:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5P24gM8084073 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5P24f8B084072; Sun, 25 Jun 2017 05:04:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Jun 2017 05:04:41 +0300 From: Konstantin Belousov To: Manfred Antar Cc: FreeBSD Current Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Message-ID: <20170625020441.GT3437@kib.kiev.ua> References: <44028FBF-C8B1-4A69-B798-F4E28CFCD779@pozo.com> <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 02:04:47 -0000 On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > > > On Jun 24, 2017, at 6:23 PM, Konstantin Belousov wrote: > > > > On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > >> New world and kernel r320323 > >> I get a new error or message when using ruby: > >> > >> > >> /usr/local/sbin/portupgrade -av > >>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > >> > >> everything works just this message when using ruby. I recompiled ruby , still same message > >> > >> /usr/local/bin/ruby -v > >>
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > >> > >> Not sure what???s changed, I noticed some commits to vm stuff, maybe thats it. > > > > ktrace your failing ruby invocation, then post output of kdump -H somewhere. > > > > Ok not sure if this is right , but this is what i did: > > (tmp)4637}ktrace /usr/local/bin/ruby -v >
: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken > ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt > > you can get kdump.txt at: > > http://www.pozo.com/kernel/kdump .txt > > It???s not failing, I don???t think , I can do portupgrade and it works fine. > I just get this new message I see what is going on, but it is somewhat strange that it happens. Do you run ruby in a jail with old (say, stable/10) libthr ? Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in your environment ? Anyway, the rework of the stack grow indeed have incompatibility with the old (pre-11) libthr, which tries to split main thread stack into smaller stacks for the new threads. New stack grow code was specifically designed to prevent this. Some hack would be needed there, to allow reuse of the main stack gap.