Bug 10223 - libbfd returns messed up data (symbol->section == 0x109 or other strange values)
Summary: libbfd returns messed up data (symbol->section == 0x109 or other strange values)
Status: RESOLVED INVALID
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.19
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-01 14:17 UTC by Albert Zeyer
Modified: 2009-06-05 05:40 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Albert Zeyer 2009-06-01 14:17:12 UTC 
It seems that libbfd is returning some messed up data structures in some cases.
In my case, symbol->section is messed up for all symbols. It always points to
some uninitialised memory.

I have seen this while using oprofile and having a segfault in opreport (while
opreport tried to access sym->section).

Here are more details, with full listings of the data structures:
https://sourceforge.net/tracker/index.php?func=detail&aid=2798666&group_id=16191&atid=116191
Comment 1 Albert Zeyer 2009-06-01 14:19:43 UTC 
To be more exact, this is with binutils-2.19.1. I also tried binutils-2.18 and
have some very similar behaviour there. (You can see more details in the
oprofile bug report.)
Comment 2 Alan Modra 2009-06-04 09:31:02 UTC 
Most likely you have built oprofile using bfd headers that don't match the
libbfd you are linking against.
Comment 3 Albert Zeyer 2009-06-04 17:23:48 UTC 
Thanks a lot, that was the problem. It seems that I had left an old bfd.h in
/usr/local/includes and all system build scripts (Gentoo Portage) used that one
instead of the one in /usr/include. Removing the file from /usr/local/include,
recompiling binutils and oprofile solved the problem.
Comment 4 Alan Modra 2009-06-05 05:40:58 UTC 
.