From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 32CD51397F2 for ; Fri, 21 Aug 2015 16:29:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 17C0BE0896; Fri, 21 Aug 2015 16:29:10 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E01BFE088B for ; Fri, 21 Aug 2015 16:29:08 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZSpBi-0005xg-5g for gentoo-user@lists.gentoo.org; Fri, 21 Aug 2015 18:29:06 +0200 Received: from 67-130-15-94.dia.static.qwest.net ([67.130.15.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Aug 2015 18:29:06 +0200 Received: from grant.b.edwards by 67-130-15-94.dia.static.qwest.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Aug 2015 18:29:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Grant Edwards Subject: [gentoo-user] Re: Epic list of total FAIL. Date: Fri, 21 Aug 2015 16:28:47 +0000 (UTC) Message-ID: References: <55D637E0.3080409@verizon.net> <55D65554.1010608@verizon.net> <55D67CD2.3030400@wraeth.id.au> <55D683C1.7020100@verizon.net> <55D68FCF.6020105@wraeth.id.au> <55D6C0AD.8060501@gmail.com> <55D73D00.3080308@verizon.net> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 67-130-15-94.dia.static.qwest.net User-Agent: slrn/1.0.2 (Linux) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Archives-Salt: c7396ddf-d1e7-49a0-88f9-2437508e88d8 X-Archives-Hash: 8f566059d8bdf8015b5a520a60ce100e On 2015-08-21, Alan Grimes wrote: > Grant Edwards wrote: >> On 2015-08-21, Alan McKinnon wrote: >> >>> Earlier I saw segfaults in gcc, and another poster pointed it out. >>> >>> When gcc segfaults, it is always suspicious mostly because the compiler >>> is an app where we know the devs take extraordinary measures to prevent it. >>> >>> The most common cause is faulty hardware (most often memory) as gcc >>> tends to use all of it in ways no other app does. The usual procedure >>> at this point is to run memtest for an extended period - say 48 >>> hours, or even 72 for an older slow machine. >> That is definitely good advice. I've run into this situation several >> times. A machine had bad RAM that didn't seem to cause any problems >> under "normal" operation. But, when trying to compile something large >> like gcc, I would see non-repeatable segfaults (it wouldn't always >> segfault at the exact same point). In those cases, I could often run >> memtest for several passes and not see an error. But, _eventually_ >> ramtest would catch it. Run memtest for a few days. Really. > > Yeah, I know there's a single bit error out at the end of RAM that > will appear on the third or fourth pass... And you're still using it? And when it doesn't work, you blame blaming _us_? **PLONK** > It just doesn't seem reasonable to demand that every bit in a 32 > gigabyte memory bank be absolutely perfect.... Idiot. Of _course_ software expects memory to work. Why don't you stop bothering us and go write an OS that doesn't depend on RAM working properly. -- Grant Edwards grant.b.edwards Yow! Now KEN and BARBIE at are PERMANENTLY ADDICTED to gmail.com MIND-ALTERING DRUGS ...