Bug 997564 - libstdc++ bad_exception::what() symbol wrong in so
libstdc++ bad_exception::what() symbol wrong in so
Product: Fedora
Classification: Fedora
Component: libstdc++so7 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matt Newsome
Depends On:
  Show dependency treegraph
Reported: 2013-08-15 11:44 EDT by Jon Robison
Modified: 2013-08-15 15:22 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-15 15:22:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jon Robison 2013-08-15 11:44:09 EDT
Description of problem:
'readelf -s /usr/lib/libstdc++.so.6.0.18 | grep bad_exception4wha' curiously returns _ZNKSt13bad_exception4wha@@GLIBCXX_3.4.9. It should return _ZNKSt13bad_exception4whatEv (note the last three characters are cut off), which c++filt can then resolve as std::bad_exception::what() const

Version-Release number of selected component (if applicable):
Fedora 19, libstdc++-4.8.1-1.fc19.x86_64 (and 32 bit)

How reproducible:

Steps to Reproduce:
1.readelf -s /usr/lib/libstdc++.so.6.0.18 | grep bad_exception4wha
2.Run c++filt on that string and note how it doesn't resolve correctly
3.Run c++filt on what it should be _ZNKSt13bad_exception4whatEv and note it resolves correctly

Actual results:
Fail to resolve correctly

Expected results:
Step 1 would include the missing "tEv", then resulting in step 2 resolving the correct name

Additional info:
If one tries to build certain libraries, this symbol may be included. Then you have a problem at runtime, not compile, which is intriguing.
Comment 1 Jon Robison 2013-08-15 15:22:03 EDT
Nevermind, readelf apparently ran out of space, I sanity checked with 'nm -D /usr/lib64/libstdc++.so.6 | grep bad_excep', then 'nm -DC /usr/lib64/libstdc++.so.6 | grep bad_exception::what' did resolve correctly.

Note You need to log in before you can comment on or make changes to this bug.