From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26831 invoked by alias); 13 Jan 2007 15:21:09 -0000 Received: (qmail 26817 invoked by uid 22791); 13 Jan 2007 15:21:07 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 13 Jan 2007 15:21:01 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H5kgl-00076w-E7; Sat, 13 Jan 2007 10:20:59 -0500 Date: Sat, 13 Jan 2007 15:21:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb@sourceware.org Subject: Re: bigcore.exp on 64-bit systems Message-ID: <20070113152058.GA27250@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00234.txt.bz2 On Sat, Jan 13, 2007 at 04:09:37PM +0200, Eli Zaretskii wrote: > I'm trying to run the testsuite on a 64-bit machine that identifies > itself thusly: > > Linux fencepost 2.6.16.29-xen #1 SMP Wed Dec 6 07:32:36 EST 2006 x86_64 GNU/Linux Hi fencepost! :-) > On this machine, bigcore.exp is a pest: it runs for a very long time, > produces a humongous core file (so large that I expect the sysadmins > to send me angry emails), and eventually fails (or so it seems). > Here's what gdb.sum says about it: The core file is probably not that large. Could you check with 'du'? As Mark said, it's supposed to be a sparse file - in case you're not familiar with them, that means that ls -l will show something huge but du will show something quite small. Most of the all-zero blocks will not have any on-disk representation. Of course, how efficient large sparse files are depends on the filesystem. I've never used xfs; it might be an xfs-specific problem. Also, I know that there was a problem in the 2.6.1x series somewhere (bad choice of locking) that led to this test taking a really long time - but I don't know what version was affected. It's not necessarily a problem on a 64-bit system; I run it on one normally. It takes twenty or thirty seconds to dump core, which is much longer than it ought to take, but much shorter than it's taking for you. I'm not sure what to suggest :-( If it is a sufficient nuisance, perhaps we should add a way for you to disable the test. -- Daniel Jacobowitz CodeSourcery