Bug 518561

Description of problem:
Our application binaries are compiled with gcc 4.2.4 (4.1.1-51.fc5), and link to libraries built with same under FC5. We noticed that while running FC11, attaching gdb (6.8.50.20090302-33.fc11) to such a binary causes gdb to hang, and the CPU is pinned. Attaching another gdb to the hung gdb shows that the following events have transpired:

1) elf_syms_from_objfile is called to load the symbols from libstdc++.so.6
2) dwarf2_create_quick_addrmap calls read_comp_unit_hyead on the abfd structure for this so.
3) the cu_header structure returned is mostly null (most critically, cu_header.addr_size).
4) dwarf2_create_quick_addrmap attempts to align a pointer, and ends up dividing by zero because cu_header.addr_size is zero.
5) gdb jumps to handle_sigfpe, at gdb/event-top.c:1030
6) eventually, we end up back in dwarf2_create_quick_addrmap, where we again divide by zero.
7) goto 5

I've attached an archive that contains a dummy program and our current FC5 libstdc++ and libgcc_s (4.1.1-51.fc5). Running make will produce a binary called 'dummy'. Launch gdb (6.8.50.20090302-33.fc11) on this binary and run to reproduce the above behavior. I was able to reproduce with the dummy binary compiled using FC5 g++ (4.2.4) and with FC11 g++ (4.4.0-4).

Version-Release number of selected component (if applicable):


How reproducible:
Every time


Steps to Reproduce:
1. see above
2.
3.
  
Actual results:
gdb pegs the CPU in an infinite divide-by-zero loop

Expected results:
gdb understands the old libraries' abfd information and completes normallyDescription of problem:

Our application binaries are compiled with gcc 4.2.4 (4.1.1-51.fc5), and link to libraries built with same under FC5. We noticed that while running FC11, attaching gdb (6.8.50.20090302-33.fc11) to such a binary causes gdb to hang, and the CPU is pinned. Attaching another gdb to the hung gdb shows that the following events have transpired:

1) elf_syms_from_objfile is called to load the symbols from libstdc++.so.6
2) dwarf2_create_quick_addrmap calls read_comp_unit_hyead on the abfd structure for this so.
3) the cu_header structure returned is mostly null (most critically, cu_header.addr_size).
4) dwarf2_create_quick_addrmap attempts to align a pointer, and ends up dividing by zero because cu_header.addr_size is zero.
5) gdb jumps to handle_sigfpe, at gdb/event-top.c:1030
6) eventually, we end up back in dwarf2_create_quick_addrmap, where we again divide by zero.
7) goto 5

I've attached an archive that contains a dummy program and our current FC5 libstdc++ and libgcc_s (4.1.1-51.fc5). Running make will produce a binary called 'dummy'. Launch gdb (6.8.50.20090302-33.fc11) on this binary and run to reproduce the above behavior. I was able to reproduce with the dummy binary compiled using FC5 g++ (4.2.4) and with FC11 g++ (4.4.0-4).

How reproducible:
Every time

Steps to reproduce:
see above

Actual results:
gdb pegs the CPU in an infinite divide-by-zero loop

Expected results:
gdb understands the old libraries' abfd information and completes normally 

Additional info: