+++ This bug was initially created as a clone of Bug #222814 +++

Description
-----------
gdb-6.5-16.el5.x86_64 coredumps if the executable size being debugged is greater
than 2 GB (approx. 2147483648 bytes).

Summary of Problem
------------------
Where does the problem occur?
During 2GB buffer allocation to read the executable.
In GDB 6.4, file dwarf2read.c, function dwarf2_read_section(), line 4951, the
following call does not return a good buffer.
buf = (char *) obstack_alloc (&objfile->objfile_obstack, size);

We suspect that this function cannot allocate more than 2GB because the size
parameter is an int (which cannot hold a number more than 2147483648).

Because of the bad buffer, reading in the executable causes a core dump later on
in the same function at bfd_bread (buf, size, abfd) != size  (dwarf2read.c, line
4957) The stack trace that shows causes this problem is:
fread          [libc.so.6]
cache_bread    [cache.c:301]
bfd_bread      [bfdio.c:140]
dwarf2_read_section [dwarf2read.c:4957]


Details (Debugging GDB 6.4 with GDB)
------------------------------------
(gdb) run
Starting program: /remote/toolsrules3/seto/gdb-6.4/bin/gdb
/remote/sde101/ryang/z2_build_ryang/object_root/bin-amd64/galaxy_icc_exec-G
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
Breakpoint 1, dwarf2_read_section (objfile=0x11bde08, sectp=0x11bde08) at
dwarf2read.c:4943
4943    {
(gdb) n
4944      bfd *abfd = objfile->obfd; 
(gdb) n
4946      bfd_size_type size = bfd_get_section_size (sectp);
(gdb) n
4948      if (size == 0)
(gdb) n
4951      buf = (char *) obstack_alloc (&objfile->objfile_obstack, size);
(gdb) p buf
$31 = 0x0 
(gdb) p size
$32 = 2266851263
(gdb) p objfile->objfile_obstack
$33 = {chunk_size = 4072, chunk = 0x15f2778, object_base = 0x15f2808 "\\a",
  next_free = 0x15f2808 "\\a", chunk_limit = 0x15f3760 "", temp = 0,
alignment_mask = 7,
  chunkfun = 0x4b80e8 <xmalloc>, freefun = 0x4b8640 <xfree>, extra_arg = 0x0,
  use_extra_arg = 0, maybe_empty_object = 0, alloc_failed = 0}
(gdb) n
4952      retbuf
(gdb) p buf
$34 = 0x15f2808 "\\a"
(gdb) p size
$35 = 2266851263
(gdb) p objfile->objfile_obstack
$36 = {chunk_size = 4072, chunk = 0x15f2778,
  object_base = 0xffffffff887c8fc8 <Address 0xffffffff887c8fc8 out of bounds>,
  next_free = 0xffffffff887c8fc8 <Address 0xffffffff887c8fc8 out of bounds>,
  chunk_limit = 0x15f3760 "", temp = 0, alignment_mask = 7, chunkfun = 0x4b80e8
<xmalloc>,
  freefun = 0x4b8640 <xfree>, extra_arg = 0x0, use_extra_arg = 0,
maybe_empty_object = 0,
  alloc_failed = 0}
(gdb) n
4954      if (retbuf != NULL)
(gdb) n
4957      if (bfd_seek (abfd, sectp->filepos, SEEK_SET) != 0
(gdb) n
bfd_bread (ptr=0x15f2788, size=18603528, abfd=0x11ba7a8) at bfdio.c:116
116     {
(gdb) n
0x000000000048d4e1 in _P_SUB_SP ()
(gdb) n
Single stepping until exit from function _P_SUB_SP,
which has no line number information.
0x000000000048b070 in _p976static ()
(gdb) n
Single stepping until exit from function _p976static,
which has no line number information.
0x000000000048d521 in _P_SUB_SP ()
(gdb) n
Single stepping until exit from function _P_SUB_SP,
which has no line number information.
0x000000000048d565 in _P_CHANGE_SP ()
(gdb) n
Single stepping until exit from function _P_CHANGE_SP,
which has no line number information.
bfd_bread (ptr=0x15f2808, size=2266851263, abfd=0x11abf28) at bfdio.c:119
119       if ((abfd->flags & BFD_IN_MEMORY) != 0)
(gdb) n
139       if (abfd->iovec)
(gdb) n
140         nread = abfd->iovec->bread (abfd, ptr, size);
(gdb) p ptr
$37 = (void *) 0x15f2808
(gdb) p size
$38 = 2266851263
(gdb) n
143       if (nread != (size_t) -1)
(gdb) p nread
$39 = 18446744073709551615
(gdb) n
146       return nread;
(gdb) n
147     }
(gdb) n
0x000000000048d52c in _P_CHANGE_SP ()
(gdb) n
Single stepping until exit from function _P_CHANGE_SP, 
which has no line number information.
0x000000000048b450 in _p1184static ()
(gdb) n
Single stepping until exit from function _p1184static,
which has no line number information.
0x000000000048d547 in _P_CHANGE_SP ()
(gdb) n
Single stepping until exit from function _P_CHANGE_SP,
which has no line number information.
0x0000000000b4a659 in bfd_bread (ptr=0x15f2788, size=18603528, abfd=0x11ba7a8)
at bfdio.c:147
147     }
(gdb) n
dwarf2_read_section (objfile=0x11bde08, sectp=0x11ba7a8) at dwarf2read.c:4959
4959        error (_("Dwarf Error: Can't read DWARF data from '%s'"),
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x0000002a95bb9a92 in _int_malloc ()
   from
/remote/toolsrules3/seto/gdb_src/pcache64/lib64/tls/libc.so.6_pure_p3_c0_109252015_2421-40ELsmp_64
(gdb) info b
Num Type           Disp Enb Address            What
1   breakpoint     keep y   0x000000000088d9f4 in dwarf2_read_section at
dwarf2read.c:4943
        breakpoint already hit 1 time
(gdb) 


From the original problem report:

...
(gdb) n
4951      buf = (char *) obstack_alloc (&objfile->objfile_obstack, size);
(gdb) p buf
$31 = 0x0
(gdb) p size
$32 = 2266851263
...

segfault is due to NULL buf earlier.


Arg 2 to obstack_alloc should be int. The allocation fails if the size
specified is larger then the max value of int. There should also be a check
to see that buf actually gets allocated in
gdb/dwarf2read.c:dwarf2_read_section.


-- Additional comment from jan.kratochvil on 2007-01-26 18:34 EST --
Confirming the bugreport is now understood as there is a problem GDBing (small)
executables using shared libraries with DWARF sections >2GB.

If they use -ggdb3 suggesting to use -ggdb2 as the macros are usually not used
and they cost a lot of DWARF space.


-- Additional comment from jan.kratochvil on 2007-01-30 15:00 EST --
As this problem is more general it has been posted for approval to glibc upstream:
http://sourceware.org/ml/libc-alpha/2007-01/msg00090.html

Bug processing has been suspended for 1-2 weeks until the upstream maintainer
Ulrich Drepper (of Red Hat) gets available for glibc again.


-- Additional comment from jan.kratochvil on 2007-03-11 12:21 EST --
Created an attachment (id=149794)
Testcase for the _libraries_ with >2GB `.debug_macinfo'.

After a build on >5GB RAM machine the old GDB:
$ gdb ./main
...
(gdb) start
Breakpoint 1 at 0x400638: file main.c, line 5.
Starting program: /root/jkratoch/redhat/testcase/main
Segmentation fault

The new GDB in a default way (ulimit -s 10240):
$ ~/redhat/gdb-6.3.0.0-1.136.el3.x86_64/usr/bin
/gdb ./main
...
(gdb) start
Breakpoint 1 at 0x400638: file main.c, line 5.
Starting program: /root/jkratoch/redhat/testcase-build/main
main () at main.c:5
5         libfunc ();
(gdb) step
Segmentation fault

And the right way:
$ ulimit -s unlimited
$ ~/redhat/gdb-6.3.0.0-1.136.el3.x86_64/usr/bin/gdb ./main 
...
(gdb) start 
Breakpoint 1 at 0x400638: file main.c, line 5.
Starting program: /root/jkratoch/redhat/testcase-build/main
main () at main.c:5
5         libfunc (); 
(gdb) step 
libfunc () at library.c:6
6       }
(gdb) 


-- Additional comment from jan.kratochvil on 2007-03-12 09:18 EST --
Created an attachment (id=149820)
Testcase for the _libraries_ with >2GB `.debug_macinfo'. (v2)

Testcase bugfix (for x86_64).