Description of problem: valgrind does not work with KDE applications. Version-Release number of selected component (if applicable): valgrind-3.8.0-4.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. valgrind kwrite Actual results: ==5430== Memcheck, a memory error detector ==5430== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==5430== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info ==5430== Command: kwrite ==5430== --5430-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --5430-- si_code=1; Faulting address: 0x403796000; sp: 0x4030d1018 valgrind: the 'impossible' happened: Killed by fatal signal ==5430== at 0x380D3B00: read_leb128 (readdwarf.c:221) ==5430== by 0x380D3B96: read_leb128U (readdwarf.c:247) ==5430== by 0x380D6294: vgModuleLocal_read_debuginfo_dwarf3 (readdwarf.c:956) ==5430== by 0x38085FEF: vgModuleLocal_read_elf_debug_info (readelf.c:2682) ==5430== by 0x3807EED5: vgPlain_di_notify_mmap (debuginfo.c:628) ==5430== by 0x380A0E68: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2066) ==5430== by 0x380CA0C4: vgSysWrap_amd64_linux_sys_mmap_before (syswrap-amd64-linux.c:1012) ==5430== by 0x3809D9B2: vgPlain_client_syscall (syswrap-main.c:1464) ==5430== by 0x3809A6FF: handle_syscall (scheduler.c:1057) ==5430== by 0x3809BC36: vgPlain_scheduler (scheduler.c:1335) ==5430== by 0x380AB739: run_a_thread_NORETURN (syswrap-linux.c:103) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==5430== at 0x30C8217A0A: mmap (syscall-template.S:81) ==5430== by 0x30C82068DB: _dl_map_object_from_fd (dl-load.c:1344) ==5430== by 0x30C82083C2: _dl_map_object (dl-load.c:2359) ==5430== by 0x30C820CCE1: openaux (dl-deps.c:63) ==5430== by 0x30C820EDC5: _dl_catch_error (dl-error.c:177) ==5430== by 0x30C820D3C1: _dl_map_object_deps (dl-deps.c:256) ==5430== by 0x30C820377B: dl_main (rtld.c:1834) ==5430== by 0x30C821529A: _dl_sysdep_start (dl-sysdep.c:242) ==5430== by 0x30C8204FC1: _dl_start (rtld.c:336) ==5430== by 0x30C8201597: ??? (in /usr/lib64/ld-2.16.so) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. Expected results: No crash
Replicated with kwrite-4.9.0-1.fc18.x86_64 and debuginfo installed. The problem seems to be that read_unitinfo_dwarf2 tries to scan for all compile units, but doesn't handle DW_TAG_imported_unit, and then just falls off the end of the image (there is a check against that, but that apparently is wrong).
Think I found the issue. See patch attached to upstream bug https://bugs.kde.org/show_bug.cgi?id=305513
valgrind-3.8.0-5.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/valgrind-3.8.0-5.fc18
Package valgrind-3.8.0-5.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing valgrind-3.8.0-5.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-12754/valgrind-3.8.0-5.fc18 then log in and leave karma (feedback).
valgrind-3.8.0-5.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
valgrind-3.8.1-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/valgrind-3.8.1-3.fc17
The 1:valgrind-3.8.1-9.el6.x86_64 is still broken on RHEL-6.9. I had to forcibly (--nodeps) upgrade my machine to valgrind-3.13.0-17.fc29.x86_64 to obtain a usable valgrind.
(In reply to Mikhail T. from comment #7) > The 1:valgrind-3.8.1-9.el6.x86_64 is still broken on RHEL-6.9. > > I had to forcibly (--nodeps) upgrade my machine to > valgrind-3.13.0-17.fc29.x86_64 to obtain a usable valgrind. "upgrading" from rhel packages to fedora packages is not supported. Please file a support request for your RHEL issue. There are unsupported packages for CentOS (not RHEL) in copr: https://copr.fedorainfracloud.org/coprs/mjw/valgrind-3.13.0/
Thanks for the pointer, Mark. I am well aware, that using Fedora packages on RHEL is not supported. My point was, valgrind-3.8.1-9 remains broken on el6 -- 6 years after valgrind-3.8.1-3 was declared a fix for fc17. > Please file a support request for your RHEL issue. For that my Bugzilla-account would need to be linked to a valid RHEL license, wouldn't it? And at my current employer, that is not my role. If you are in CC on this ticket, you should be able to verify my claim on a proper RHEL-6 system in seconds. If you -- or anyone else here -- are interested in fixing the actual problem, you have all the information necessary to begin. My filing a separate ticket for it should not be necessary.
(In reply to Mikhail T. from comment #9) > Thanks for the pointer, Mark. I am well aware, that using Fedora packages on > RHEL is not supported. My point was, valgrind-3.8.1-9 remains broken on el6 > -- 6 years after valgrind-3.8.1-3 was declared a fix for fc17. > > > Please file a support request for your RHEL issue. > > For that my Bugzilla-account would need to be linked to a valid RHEL > license, wouldn't it? And at my current employer, that is not my role. > > If you are in CC on this ticket, you should be able to verify my claim on a > proper RHEL-6 system in seconds. > > If you -- or anyone else here -- are interested in fixing the actual > problem, you have all the information necessary to begin. My filing a > separate ticket for it should not be necessary. I am not able to reproduce your issue, and I am not aware of any bugs filed against valgrind in RHEL that match your bug. The RHEL valgrind contains the same fixes as the fedora valgrind package for this issue. So I assume this is a different bug. The way to get this fixed is to file an issue with steps to reproduce the issue you are seeing against RHEL.