From nobody Sat Jan 04 14:57:21 2025 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YQNsw1rR3z5kMMl for ; Sat, 04 Jan 2025 15:00:36 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YQNst4ZZSz4Zrx for ; Sat, 4 Jan 2025 15:00:34 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of li-fbsd@citylink.dinoex.sub.org designates 2a0b:f840::12 as permitted sender) smtp.mailfrom=li-fbsd@citylink.dinoex.sub.org; dmarc=none; arc=pass ("uucp.dinoex.org:s=M20221114:i=1") Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.18.1/8.18.1) with ESMTPS id 504F07fb024608 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 4 Jan 2025 16:00:07 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) ARC-Seal: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1736002810; cv=none; b=p+8ta8j4O8z0p94P1fWDpgtLxMwz02tFPTIpRntsLPtA12GJl7ppji18OdeRNfoOtHjrSYCAlqSxRxvBXVNS1V1TzNCRYGpcp+LUULqMNAjpnHaBShKglK6lCtmRGLOwHAF6WhjnamQdxDMUgRfjL8uk8MQ5j5PY9CNmmTFn+gI= ARC-Message-Signature: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1736002810; c=relaxed/simple; bh=FlkfxoCllQCxeCn5p/JFMwVECGQjUw3EfAfCWqF1gw8=; h=Received:Received:Received:X-Authentication-Warning:From: X-Newsgroups:Subject:Date:Message-ID:References:Injection-Date: Injection-Info:User-Agent:To:X-Milter:X-Greylist; b=h4UxOKt/K2M1r1U4Hy1Bi+tHIsdUgdweCxv/dED34lvbTJb0Z4ow9hEN3u8pZtnpYAFcwrRJb6WqmRE/o9XgLoR/GYQ7jTl8xZg46nf34kzHK6jMZEatbOCo8umBvO3Mv1a9G0aNNGh34itVgvW7jJYmmkbTnMGxnmjjWM7y93A= ARC-Authentication-Results: i=1; uucp.dinoex.org X-MDaemon-Deliver-To: Received: (from uucp@localhost) by uucp.dinoex.org (8.18.1/8.18.1/Submit) with UUCP id 504F07FE024607 for freebsd-hackers@freebsd.org; Sat, 4 Jan 2025 16:00:07 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from admn.intra.daemon.contact (localhost [127.0.0.1]) by admn.intra.daemon.contact (8.18.1/8.18.1) with ESMTPS id 504EvjiY045091 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 4 Jan 2025 15:57:46 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from intra.daemon.contact (news@localhost) by admn.intra.daemon.contact (8.18.1/8.18.1/Submit) with NNTP id 504EvLeu044801 for freebsd-hackers@freebsd.org; Sat, 4 Jan 2025 15:57:21 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: admn.intra.daemon.contact: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: "Peter 'PMc' Much" X-Newsgroups: m2n.fbsd.hackers Subject: Re: curious crashes when under memory pressure Date: Sat, 4 Jan 2025 14:57:21 -0000 (UTC) Message-ID: References: Injection-Date: Sat, 4 Jan 2025 14:57:21 -0000 (UTC) Injection-Info: admn.intra.daemon.contact; logging-data="30144"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: slrn/1.0.3 (FreeBSD) To: freebsd-hackers@freebsd.org X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Sat, 04 Jan 2025 16:00:10 +0100 (CET) X-Rspamd-Queue-Id: 4YQNst4ZZSz4Zrx X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_ALLOW(-1.00)[uucp.dinoex.org:s=M20221114:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[pmc@citylink.dinoex.sub.org,li-fbsd@citylink.dinoex.sub.org]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_XAW(0.00)[]; ASN(0.00)[asn:205376, ipnet:2a0b:f840::/32, country:DE]; FROM_NEQ_ENVFROM(0.00)[pmc@citylink.dinoex.sub.org,li-fbsd@citylink.dinoex.sub.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[sub.org]; RCVD_TLS_LAST(0.00)[]; TO_DN_NONE(0.00)[] List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org On 2025-01-04, Chris Torek wrote: > I have my (amd64, -current) box set up to build a lot of ports in > parallel with a fairly high `make -j` value as well. This will > sometimes try to build llvm versions 15, 16, and 17 and maybe a gcc or > two and/or rustc and/or firefox etc and push the load over 100 and run > me out of real memory (currently only 64 GB). When this happens, it's > not unusual to get: "only"... ? *shrug* Similar config here, 20 core, 80 GB, 4 domains, builds run within temporary bhyves, a couple in parallel. Had a lot fun getting llvm builds to run along w/o mem exhaustion. > pid (c++) ... exited on signal 4 (core dumped) > > messages on the console, occasional uprintf() messages, and a build Haven't seen exactly that one yet. > failure -- which goes away when retrying. It's not a parallel make > jobs issue. It *appears* to have something to do with the copyout() > calls for signal handlers failing, and it invariably coincides with > increasing swap usage. I'm swapping to a zfs mirror Well, You shouldn't do that. Swapping back onto ZFS does usually work for some individual process that needs a lot of memory, for some in-memory array or such - i.e. for desktop uses. I never expected it to work when the entire system runs from paging. In any case, looping back the swap onto ZFS is logically bogus. So, get one or two decent SSD, put the swap onto raw partitions, and test with that, to see if the issue reproduces. Only then I would try and search further for the actual cause.