Date: Wed, 12 Jul 2017 11:09:32 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: jasone@canonware.com Cc: jasone@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: jemalloc_arena.c:821: Failed assertion: "nstime_compare(&decay->epoc h, &time) <= 0") Message-ID: <201707121809.v6CI9WSk059429@gw.catspoiler.org> In-Reply-To: <20170712090649.bb0aa3e8d4e745fce515ca48@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Jul, Jason Evans wrote: > On Tue, 11 Jul 2017 18:12:58 -0700 (PDT) > Don Lewis <truckman@FreeBSD.org> wrote: >> I'm trying to stabilize my new-ish Ryzen package build box. I've run >> into this error a couple of times: >> (<jemalloc>: 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201707121809.v6CI9WSk059429>