From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-27481-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 5076 invoked by alias); 13 Jan 2007 14:50:47 -0000
Received: (qmail 5068 invoked by uid 22791); 13 Jan 2007 14:50:47 -0000
X-Spam-Check-By: sourceware.org
Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 13 Jan 2007 14:50:42 +0000
Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) 	by brahms.sibelius.xs4all.nl (8.13.8/8.13.8) with ESMTP id l0DEoY7n027415; 	Sat, 13 Jan 2007 15:50:34 +0100 (CET)
Received: (from kettenis@localhost) 	by brahms.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id l0DEoWpP029656; 	Sat, 13 Jan 2007 15:50:32 +0100 (CET)
Date: Sat, 13 Jan 2007 14:50:00 -0000
Message-Id: <200701131450.l0DEoWpP029656@brahms.sibelius.xs4all.nl>
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: eliz@gnu.org
CC: gdb@sourceware.org
In-reply-to: <u4pqvhvby.fsf@gnu.org> (message from Eli Zaretskii on Sat, 13 	Jan 2007 16:09:37 +0200)
Subject: Re: bigcore.exp on 64-bit systems
References:  <u4pqvhvby.fsf@gnu.org>
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2007-01/txt/msg00229.txt.bz2

> Date: Sat, 13 Jan 2007 16:09:37 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
>     Running ../.././gdb/testsuite/gdb.base/bigcore.exp ...
>     PASS: gdb.base/bigcore.exp: set print sevenbit-strings; bigcore
>     PASS: gdb.base/bigcore.exp: set width 0; bigcore
>     PASS: gdb.base/bigcore.exp: tbreak 264
>     PASS: gdb.base/bigcore.exp: continue
>     PASS: gdb.base/bigcore.exp: next
>     PASS: gdb.base/bigcore.exp: extract next heap (stop at 50)
>     PASS: gdb.base/bigcore.exp: extract prev heap (stop at 50)
>     PASS: gdb.base/bigcore.exp: save heap size
>     PASS: gdb.base/bigcore.exp: grab pid
>     FAIL: gdb.base/bigcore.exp: signal SIGABRT (timeout)
>     FAIL: gdb.base/bigcore.exp: check core size (timeout)
>     UNTESTED: gdb.base/bigcore.exp: check core size (system does not support large corefiles)
> 
> Is this normal?  What is the meaning of SIGABRT (timeout), and what,
> if anything, should I do about the last line?

It's not normal.  On a modern Linux kernel this test should pass, and
2.6.16 certainly qualifies as modern.  The idea is that the test will
create a sparse core file, that will take up almost no disk space.
But the fact that it takes more than 600 seconds to dump the core file
(that's the cause of the SIGABRT timeout), suggests that it isn't
doing that.

Are you by any chance running this on an NFS filesystem?

Mark