This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: bigcore.exp on 64-bit systems
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: eliz at gnu dot org
- Cc: gdb at sourceware dot org
- Date: Sat, 13 Jan 2007 15:50:32 +0100 (CET)
- Subject: Re: bigcore.exp on 64-bit systems
- References: <u4pqvhvby.fsf@gnu.org>
> 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