Bug 676785
| Summary: | Valgrind finds jump issue in ld-2.13.so.x86_64 (glibc-2.13.fc14.x86_64) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ken <kj.riedel> | ||||
| Component: | valgrind | Assignee: | Jakub Jelinek <jakub> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 14 | CC: | dodji, fedorabugmail, jakub, kgiusti, malte, schwab | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | valgrind-3.5.0-20.fc14 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-03-05 02:27:11 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Is this a valgrind issue? If the same version of valgrind works with an older version of ld.so, then why wouldn't it also work with the newer version?
The only dl-related change I could find in the glibc changelog was:
* Fri Nov 12 2010 Andreas Schwab <schwab> - 2.12.90-19
- Fix concurrency problem between dl_open and dl_iterate_phdr
Not sure if this has anything to do with the problem
Nevermind last comment. Grabbed latest valgrind from koji built against glibc 2.13 and that seems to have fixed the problem. Would it possible to also have valgrind rebuilt against new glibc for dist-f14 repository? *** Bug 677486 has been marked as a duplicate of this bug. *** I see this as well. Valgrind complains for any program, not just those compiled by the user. As Ken pointed out, there is a new version of Valgrind to address this. valgrind-3.5.0-20.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/valgrind-3.5.0-20.fc14 valgrind-3.5.0-20.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update valgrind'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/valgrind-3.5.0-20.fc14 Thank you for F14 rebuild against new glibc. Everything appears to work as it should with valgrind-3.5.0-20.fc14. I suppose once it is pushed from testing to final release, this bug can be closed. The new valgrind version did also solve the problem for me, thanks! valgrind-3.5.0-20.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. |
Created attachment 478195 [details] Hello World Test Description of problem: Using Fedora 14 x86_64 with gcc-4.5.1-4 and valgrind-3.5.0 Updated from glibc-2.12.90-17.fc14.x86_64 to glibc-2.13-1.fc14.x86_64 today. Afterwards, I noticed that compiling any C program (including simple hello world program) and running through valgrind memory checker produces the following output: ==4995== Memcheck, a memory error detector ==4995== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==4995== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==4995== Command: ./hello ==4995== ==4995== Conditional jump or move depends on uninitialised value(s) ==4995== at 0x4016AA6: index (in /lib64/ld-2.13.so) ==4995== by 0x4007084: expand_dynamic_string_token (in /lib64/ld-2.13.so) ==4995== by 0x40078E9: _dl_map_object (in /lib64/ld-2.13.so) ==4995== by 0x400126D: map_doit (in /lib64/ld-2.13.so) ==4995== by 0x400DC65: _dl_catch_error (in /lib64/ld-2.13.so) ==4995== by 0x4001186: do_preload (in /lib64/ld-2.13.so) ==4995== by 0x4003FC8: dl_main (in /lib64/ld-2.13.so) ==4995== by 0x401465A: _dl_sysdep_start (in /lib64/ld-2.13.so) ==4995== by 0x40048C0: _dl_start (in /lib64/ld-2.13.so) ==4995== by 0x4000B27: ??? (in /lib64/ld-2.13.so) ==4995== ==4995== Conditional jump or move depends on uninitialised value(s) ==4995== at 0x4016AAB: index (in /lib64/ld-2.13.so) ==4995== by 0x4007084: expand_dynamic_string_token (in /lib64/ld-2.13.so) ==4995== by 0x40078E9: _dl_map_object (in /lib64/ld-2.13.so) ==4995== by 0x400126D: map_doit (in /lib64/ld-2.13.so) ==4995== by 0x400DC65: _dl_catch_error (in /lib64/ld-2.13.so) ==4995== by 0x4001186: do_preload (in /lib64/ld-2.13.so) ==4995== by 0x4003FC8: dl_main (in /lib64/ld-2.13.so) ==4995== by 0x401465A: _dl_sysdep_start (in /lib64/ld-2.13.so) ==4995== by 0x40048C0: _dl_start (in /lib64/ld-2.13.so) ==4995== by 0x4000B27: ??? (in /lib64/ld-2.13.so) ==4995== ==4995== Conditional jump or move depends on uninitialised value(s) ==4995== at 0x400ADA2: _dl_relocate_object (in /lib64/ld-2.13.so) ==4995== by 0x4003295: dl_main (in /lib64/ld-2.13.so) ==4995== by 0x401465A: _dl_sysdep_start (in /lib64/ld-2.13.so) ==4995== by 0x40048C0: _dl_start (in /lib64/ld-2.13.so) ==4995== by 0x4000B27: ??? (in /lib64/ld-2.13.so) ==4995== ==4995== Conditional jump or move depends on uninitialised value(s) ==4995== at 0x400ADAB: _dl_relocate_object (in /lib64/ld-2.13.so) ==4995== by 0x4003295: dl_main (in /lib64/ld-2.13.so) ==4995== by 0x401465A: _dl_sysdep_start (in /lib64/ld-2.13.so) ==4995== by 0x40048C0: _dl_start (in /lib64/ld-2.13.so) ==4995== by 0x4000B27: ??? (in /lib64/ld-2.13.so) ==4995== ==4995== Conditional jump or move depends on uninitialised value(s) ==4995== at 0x400ADA2: _dl_relocate_object (in /lib64/ld-2.13.so) ==4995== by 0x40034A5: dl_main (in /lib64/ld-2.13.so) ==4995== by 0x401465A: _dl_sysdep_start (in /lib64/ld-2.13.so) ==4995== by 0x40048C0: _dl_start (in /lib64/ld-2.13.so) ==4995== by 0x4000B27: ??? (in /lib64/ld-2.13.so) ==4995== ==4995== Conditional jump or move depends on uninitialised value(s) ==4995== at 0x400ADAB: _dl_relocate_object (in /lib64/ld-2.13.so) ==4995== by 0x40034A5: dl_main (in /lib64/ld-2.13.so) ==4995== by 0x401465A: _dl_sysdep_start (in /lib64/ld-2.13.so) ==4995== by 0x40048C0: _dl_start (in /lib64/ld-2.13.so) ==4995== by 0x4000B27: ??? (in /lib64/ld-2.13.so) ==4995== hello, world ==4995== ==4995== HEAP SUMMARY: ==4995== in use at exit: 0 bytes in 0 blocks ==4995== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==4995== ==4995== All heap blocks were freed -- no leaks are possible ==4995== ==4995== For counts of detected and suppressed errors, rerun with: -v ==4995== Use --track-origins=yes to see where uninitialised values come from ==4995== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 0 from 0) Reverting back to glibc-2.12.90-17 gets rid of the messages: ==5170== Memcheck, a memory error detector ==5170== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==5170== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==5170== Command: ./hello ==5170== hello, world ==5170== ==5170== HEAP SUMMARY: ==5170== in use at exit: 0 bytes in 0 blocks ==5170== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==5170== ==5170== All heap blocks were freed -- no leaks are possible ==5170== ==5170== For counts of detected and suppressed errors, rerun with: -v ==5170== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) Is this a serious memory issue in ld-2.13.so? How reproducible: Compile any C program and run under valgrind Actual results: Valgrind reports "Conditional jump or move messages" Expected results: Valgrind shouldn't show any errors, as under the previous glibc version.