From owner-freebsd-current@freebsd.org Wed Jul 12 18:09:42 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 DF712D9F87B for ; Wed, 12 Jul 2017 18:09:42 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BF01571234; Wed, 12 Jul 2017 18:09:42 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id v6CI9WSk059429; Wed, 12 Jul 2017 11:09:36 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201707121809.v6CI9WSk059429@gw.catspoiler.org> Date: Wed, 12 Jul 2017 11:09:32 -0700 (PDT) From: Don Lewis Subject: Re: jemalloc_arena.c:821: Failed assertion: "nstime_compare(&decay->epoc h, &time) <= 0") To: jasone@canonware.com cc: jasone@FreeBSD.org, freebsd-current@FreeBSD.org In-Reply-To: <20170712090649.bb0aa3e8d4e745fce515ca48@canonware.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii 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: Wed, 12 Jul 2017 18:09:43 -0000 On 12 Jul, Jason Evans wrote: > On Tue, 11 Jul 2017 18:12:58 -0700 (PDT) > Don Lewis wrote: >> I'm trying to stabilize my new-ish Ryzen package build box. I've run >> into this error a couple of times: >> (: jemalloc_arena.c:821: Failed assertion: >> "nstime_compare(&decay->epoc h, &time) <= 0") most recently today >> when building llvm40. It seems to happen somewhat randomly. I don't >> remember seeing it before the jemalloc 5.0.0 import. >> >> What does it mean? Any ideas on how I might mitigate the problem? > > This assertion verifies that a monotonic time source is not going > backward in time. jemalloc has code for mitigating the effects of > non-monotonic time sources, but that code is only used for time source > APIs that do not promise monotonic time. Interesting ... In my case TSC is being used as the timecounter. I'm not seeing any problems with ntp, and I'm not seeing any "calcru: runtime went backwards" errors in the logs. I should be able to write some test code that specifically looks for this, but this error is pretty rare and there are bigger problems at the moment.