Re: external/1568: bigcore.exp fails on i386-linux

[Daniel Jacobowitz <drow at sources dot redhat dot com>]

The following reply was made to PR external/1568; it has been noted by GNATS.

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