Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionDominik Strasser
2011-07-29 07:41:45 UTC
Created attachment 515833[details]
Source code of the binary
Description of problem:
I have the following setup:
GCC 4.1.2 compiled on a RHEL4(CentOs 4) system.
If I compile the attached C++ source with this compiler and -O3, the executable crashes with the following backtrace:
#0 0x080491f0 in strlen@@GLIBC_2.0 ()
#1 0x00a12822 in _dl_fixup () from /lib/ld-linux.so.2
#2 0x00a18c60 in _dl_runtime_resolve () from /lib/ld-linux.so.2
#3 0x0019dd3c in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) ()
from /usr/lib/libstdc++.so.6
#4 0x08048a24 in main ()
When compiling with the binary same compiler on CentOs 4, no crash occurs.
Leaving away -O3 also doesn't crash.
Running the binary produced on CentOS 6, it doesn't crash but produces the warning:
Symbol `strlen' has different size in shared object, consider re-linking
Version-Release number of selected component (if applicable):
gcc 4.1.2
glibc 2.12-1.7
libstdc++ 4.4.4
How reproducible:
see above
Steps to Reproduce:
see above
Run the attached binary.
Actual results:
Expected results:
Additional info:
Created attachment 515833 [details] Source code of the binary Description of problem: I have the following setup: GCC 4.1.2 compiled on a RHEL4(CentOs 4) system. If I compile the attached C++ source with this compiler and -O3, the executable crashes with the following backtrace: #0 0x080491f0 in strlen@@GLIBC_2.0 () #1 0x00a12822 in _dl_fixup () from /lib/ld-linux.so.2 #2 0x00a18c60 in _dl_runtime_resolve () from /lib/ld-linux.so.2 #3 0x0019dd3c in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from /usr/lib/libstdc++.so.6 #4 0x08048a24 in main () When compiling with the binary same compiler on CentOs 4, no crash occurs. Leaving away -O3 also doesn't crash. Running the binary produced on CentOS 6, it doesn't crash but produces the warning: Symbol `strlen' has different size in shared object, consider re-linking Version-Release number of selected component (if applicable): gcc 4.1.2 glibc 2.12-1.7 libstdc++ 4.4.4 How reproducible: see above Steps to Reproduce: see above Run the attached binary. Actual results: Expected results: Additional info: