Summary: | Crash while handling DW_AT_abstract_origin for a last comp unit | ||
---|---|---|---|
Product: | binutils | Reporter: | Dmitry Smirnov <divis1969> |
Component: | binutils | Assignee: | Alan Modra <amodra> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bug-binutils |
Priority: | P2 | ||
Version: | 2.18 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | 2009-01-21 08:10:32 | |
Attachments: |
Stack of the crash
DWARF info example for the last comp unit |
Description
Dmitry Smirnov
2008-08-11 09:10:55 UTC
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. |