From: David Ronis <ronis@ronispc.chem.mcgill.ca>
To: gdb-gnats@sources.redhat.com
Cc:  
Subject: Re: external/1568: bigcore.exp fails on i386-linux
Date: Thu, 15 Apr 2004 16:58:03 -0400

 I just built gdb-6.1 from scratch using gcc-3.3.3 on an i686.  I get the 
 same testsuite failure.
 
 David
 
 

From: Daniel Jacobowitz <drow@sources.redhat.com>
To: gdb-gnats@sources.redhat.com
Cc:  
Subject: Re: external/1568: bigcore.exp fails on i386-linux
Date: Sat, 17 Apr 2004 16:52:03 -0400

 On Wed, Feb 25, 2004 at 02:24:56AM -0000, drow@sources.redhat.com wrote:
 > 
 > >Number:         1568
 > >Category:       external
 > >Synopsis:       bigcore.exp fails on i386-linux
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       medium
 > >Responsible:    unassigned
 > >State:          open
 > >Class:          external
 > >Submitter-Id:   net
 > >Arrival-Date:   Wed Feb 25 02:28:00 UTC 2004
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     drow@sources.redhat.com
 > >Release:        HEAD 2004-02-24
 > >Organization:
 > >Environment:
 > i386-linux, kernel version 2.6.3
 > >Description:
 > bigcore.exp always generates two FAILs:
 > FAIL: gdb.base/bigcore.exp: check next heap (address 0x2804a010)
 > FAIL: gdb.base/bigcore.exp: check prev heap (address 0x3ff4a050)
 > 
 > The corefile says:
 >   6 load3         37fa1000  0804a000  00000000  00002000  2**12
 >                   CONTENTS, ALLOC, LOAD, CODE
 >  16 load13        40102000  40200000  00000000  38014000  2**12
 >                   CONTENTS, ALLOC, LOAD
 >  17 load14        3fcca000  80321000  00000000  78116000  2**12
 >                   CONTENTS, ALLOC, LOAD
 > GDB says:
 > 
 > (gdb) print $.next
 > $96 = (struct list *) 0xa0322008
 > (gdb) print $.next
 > Cannot access memory at address 0xa0322008
 > 
 > which is in the range of that dumped statement.
 > 
 > This is an upgraded tree.  I'll try blowing away and reconfiguring
 > to see if it's a BFD configury issue.
 
 This happens because it does not seem that any non-RHEL Linux kernel
 sources contain the fixes for dumping large core files.  In particular,
 fs/binfmt_elf.c:dump_seek uses an 'off_t' where it ought to use a
 'loff_t'.  The resulting core file is truncated to just under 2GB.
 
 This is with the latest sources.  It should be relatively easy to
 compute the approximate expected size of the core file, and then kfail
 the test if the resulting file is too small.  I don't know if some
 other OS might make more use of PT_LOAD segments instead of sparse
 files, defeating this check.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer

From: drow@sourceware.org
To: gdb-gnats@sourceware.org
Cc:  
Subject: external/1568
Date: 10 May 2004 16:47:40 -0000

 CVSROOT:	/cvs/src
 Module name:	src
 Changes by:	drow@sourceware.org	2004-05-10 16:47:40
 
 Modified files:
 	gdb/testsuite  : ChangeLog 
 	gdb/testsuite/gdb.base: bigcore.c bigcore.exp 
 
 Log message:
 	PR external/1568
 	* gdb.base/bigcore.exp: Check the size of the dumped core file.
 	XFAIL if it is smaller than bytes_allocated.
 	* gdb.base/bigcore.c (bytes_allocated): Make static and unsigned.
 	(main): Make chunks_allocated unsigned.  Correct comment.
 
 Patches:
 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/testsuite/ChangeLog.diff?cvsroot=src&r1=1.864&r2=1.865
 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.base/bigcore.c.diff?cvsroot=src&r1=1.2&r2=1.3
 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.base/bigcore.exp.diff?cvsroot=src&r1=1.5&r2=1.6

This bug feels closable.
I'll close it in a bit if no one objects.

I think 10 years qualifies as a big enough bit.  :-)  

Closing.