For this case I was using http://www.kernel.org/pub/linux/devel/binutils/binutils-2.18.50.0.8.tar.bz2. My application is using BFD library for handling ELF file generated by ADS 1.2. Unfortunately, I cannot share this ELF file since it contains some proprietary info. Nevertheless, I suppose I can describe the condition this ELF must to conform. Application is crashing attempting to access the memory it is not allowed (SIGSEGV). See stack (from Eclipse) attached. After some debugging I found that problem is with find_line(), line 3143: if ((bfd_vma) (stash->info_ptr - stash->sec_info_ptr) == stash->sec->size) { stash->sec = find_debug_info (stash->bfd, stash->sec); stash->sec_info_ptr = stash->info_ptr; } This code is changing stash->sec and stash->sec_info_ptr if this unit was the last one. When find_abstract_instance_name() uses it later (unit->stash->sec_info_ptr), it calculates the address that is over the limits. This causes a crash. So, to be able to reproduce this test case, ELF file should contain compilation unit that is the last unit in .debug_info section (it will be better to have just one section as in my case). This unit should have DW_AT_abstract_origin for some of its subtags (in my case this was DW_TAG_subprogram. I've attached the example. I was able to fix problem locally by moving the code above to the end of the function (i.e. after the call to comp_unit_find_line). Not sure this is correct fix. Dmitry
Created attachment 2900 [details] Stack of the crash
Created attachment 2901 [details] DWARF info example for the last comp unit
I forgot to say, that test case have to call find_line() for non-existing symbol after BFD opening so the BFD try to create/parse ALL the comp units.
I've found one more test case for this crash. For this case you need to have a comp unit with low and high PC specified in DWARF info. It also should have DW_AT_abstract_origin for some of its attributes. Symbol search should be performed in 2 steps: 1. Search for a symbol for address that does not fall into any debug info. More exactly, this search should trigger all comp units of this debug section to be created. 2. Search for a symbol for address that fall into comp unit with low/high PC specified. Dmitry
Hi Dmitry, > My application is using BFD library for handling ELF file generated > by ADS 1.2. Unfortunately, I cannot share this ELF file since it > contains some proprietary info. If you run your ELF binary through "readelf -w" does it report any problems with the debug information ? Without a test case and a procedure to follow to reproduce the bug, I really do not think that we are going to be able to solve this problem. Are you sure that you cannot provide us with an ELF file ? You could always zero out the proprietary information first before uploading it. > I was able to fix problem locally by moving the code above to the > end of the function (i.e. after the call to > comp_unit_find_line). Not sure this is correct fix I think that would be the wrong way to fix the problem. It would mean that the stash pointer passed to comp_unit_find_line would be incorrect. Cheers Nick
(In reply to comment #5) > If you run your ELF binary through "readelf -w" does it report any > problems with the debug information ? Yes, a lot of. Like this: readelf: Warning: There is a hole [0xab1ea0 - 0xab2551] in .debug_loc section. readelf: Warning: There is an overlap [0xab25ab - 0xab1ea0] in .debug_loc sectio n. > Without a test case and a procedure to follow to reproduce the bug, I > really do not think that we are going to be able to solve this > problem. Are you sure that you cannot provide us with an ELF file ? > You could always zero out the proprietary information first before > uploading it. I'm afraid I will need to remove whole debug info in order to remove this proprietary info. I suppose, it is possible to generate such an ELF using GCC. I've described the conditions it has to meet. > I think that would be the wrong way to fix the problem. It would mean > that the stash pointer passed to comp_unit_find_line would be > incorrect. Maybe. Though, I believe it is also useless to pass the pointer above this section. I think this value is not used at all except handling DW_AT_abstract_origin. Dmitry
Subject: Re: Crash while handling DW_AT_abstract_origin for a last comp unit Hi Dmitry, >> If you run your ELF binary through "readelf -w" does it report any >> problems with the debug information ? > > Yes, a lot of. Like this: > readelf: Warning: There is a hole [0xab1ea0 - 0xab2551] in .debug_loc section. > readelf: Warning: There is an overlap [0xab25ab - 0xab1ea0] in .debug_loc sectio > n. So the DWARF information in the ELF file is broken ? That would explain why this problem has not been encountered by other people. >> Without a test case and a procedure to follow to reproduce the bug, I >> really do not think that we are going to be able to solve this >> problem. Are you sure that you cannot provide us with an ELF file ? >> You could always zero out the proprietary information first before >> uploading it. > > I'm afraid I will need to remove whole debug info in order to remove this > proprietary info. How can the debug info be proprietary ? Maybe some of the symbol names, but you can always change those. Cheers Nick
Subject: Bug 6832 CVSROOT: /cvs/src Module name: src Changes by: amodra@sourceware.org 2009-01-22 08:54:20 Modified files: bfd : ChangeLog dwarf2.c Log message: PR 6832 * dwarf2.c (find_line): Don't update stash->sec_info_ptr until after comp_unit_find_line call. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.4432&r2=1.4433 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/dwarf2.c.diff?cvsroot=src&r1=1.116&r2=1.117
.
Hi, While running my program with BFD 2.20.51.20090916 (which I had grabbed from GDB 7.0) I see there is still a possibility for the problem reported by this bug. It does not crash but produces a message like Dwarf Error: Could not find abbrev number The problem, on my mind, is caused by the following sequence: My program tries to locate an address and find the line number, function etc. The ELF file has just one debug info section. One of the comp unit was already loaded (by parse_comp_unit() I suppose) but scan_unit_for_symbols() was not yet called yet for it. At some stage, all the comp units of this alone sections are loaded and parsed and stash->sec_info_ptr was advanced to the end of this section (line 3224 of dwarf2.c) Finally, when find_line tries to find locate some address in this unit and scan_unit_for_symbols is called, it produces such an error message. This happens when find_abstract_instance_name() tries to read some attribute, referred by DW_FORM_ref_addr. It tries to read from beyond the scope of the debug info section due to line 1751: info_ptr = unit->stash->sec_info_ptr + die_ref; As I said before, unit->stash->sec_info_ptr is pointing to the end if section. Dmitry
Subject: Bug 6832 CVSROOT: /cvs/src Module name: src Changes by: amodra@sourceware.org 2010-01-11 08:36:19 Modified files: bfd : ChangeLog dwarf2.c Log message: PR 6832 * dwarf2.c (struct comp_unit): Add sec_info_ptr. (find_abstract_instance_name): Use it. (parse_comp_unit): Set it. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.4880&r2=1.4881 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/dwarf2.c.diff?cvsroot=src&r1=1.127&r2=1.128
Subject: Bug 6832 CVSROOT: /cvs/src Module name: src Branch: binutils-2_20-branch Changes by: amodra@sourceware.org 2010-01-11 08:37:17 Modified files: bfd : ChangeLog dwarf2.c Log message: PR 6832 * dwarf2.c (struct comp_unit): Add sec_info_ptr. (find_abstract_instance_name): Use it. (parse_comp_unit): Set it. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&only_with_tag=binutils-2_20-branch&r1=1.4761.2.36&r2=1.4761.2.37 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/dwarf2.c.diff?cvsroot=src&only_with_tag=binutils-2_20-branch&r1=1.122.4.2&r2=1.122.4.3
Should now be fixed.