This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: corefiles/2121: gdb crashes sometimes on huge segment mappings


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

From: Daniel Jacobowitz <drow@false.org>
To: lfk@kerbit.net
Cc: gdb-gnats@sources.redhat.com
Subject: Re: corefiles/2121: gdb crashes sometimes on huge segment mappings
Date: Wed, 3 May 2006 16:35:54 -0400

 On Wed, May 03, 2006 at 08:18:37PM -0000, lfk@kerbit.net wrote:
 > I'm trying to debug core files (and live processes) that have large
 > address spaces (> 2 gig data) and have found that gdb is unable to
 > deal with some of the resulting core files.  I had been using the
 > 6.1post packages from RedHat which contain fixes for largefile
 > support in the BFD library and other areas and recently decided to
 > try upgrading to the 6.4 release (the number of patches in 6.1post is
 > quite large) because I would occasionally come across a process/core
 > that GDB couldn't handle.
 > 
 > There is a fundamental issue with the code that handles segment
 > mappings in the inferior process or core file when those mappings are
 > larger than SSIZE_MAX (2G - 1 on x86/32bit).  The fread/fwrite stdio
 > calls simply return 0 if the size (after being munged into a signed
 > type) is < 0.  This results in both unreadable core files and gdb
 > crashes at times.
 
 > >How-To-Repeat:
 
 > Create a program that mallocs a 2.2GB chunk of space (note a large
 > memory RedHat ES/AS config may be required), run it under gdb.
 
 That's not much information about how to reproduce it.  What did you
 have to _do_ in GDB to cause a problem?
 
 I think your patch is barking up the wrong tree; these interfaces are
 perfectly fine, they're just not supposed to be used for unboundedly
 large transfers.  If GDB ever needs to malloc a 2.2GB buffer to read
 into, it's already doing something wrong.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]