This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
Re: corefiles/2121: gdb crashes sometimes on huge segment mappings
- From: Daniel Jacobowitz <drow at false dot org>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 3 May 2006 20:38:01 -0000
- Subject: Re: corefiles/2121: gdb crashes sometimes on huge segment mappings
- Reply-to: Daniel Jacobowitz <drow at false dot org>
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