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 IST by Albert Zeyer
Modified: 2009-06-05 05:40 IST (History)
1 user (show)

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


Attachments

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 IST
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 IST
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 IST
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 IST
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 IST
.