Created attachment 112030 [details] Failure report for Memcheck 3.14.0.GIT on High Sierra I built the HEAD of Valgrind (3.14.0.GIT) via Homebrew, in order to use it on my recently upgraded MacOSX High Sierra system. When I run Memcheck with my application, it crashes out with the attached log file. The key line is valgrind: m_debuginfo/debuginfo.c:452 (void discard_or_archive_DebugInfo(DebugInfo *)): Assertion 'is_DebugInfo_active(di)' failed. I can confirm that my application (a Geant4 executable) and its associated shared libraries are all built with debugging symbols included. Given the various ongoing problems with High Sierra, I marked this as an OS-specific issue, probably not a general "bug" in Valgrind.
Have seen the same. A quick workaround seems to shortcut is_DebugInfo_active: From be6aba76267a1302fb72db8836e83023e4971203 Mon Sep 17 00:00:00 2001 From: Ellis Breen <ellis.breen@couchbase.com> Date: Tue, 26 Jun 2018 17:32:54 +0100 Subject: [PATCH] 393146: Temporary workaround for Darwin --- coregrind/m_debuginfo/debuginfo.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/coregrind/m_debuginfo/debuginfo.c b/coregrind/m_debuginfo/debuginfo.c index 13991b69a..ab05330b4 100644 --- a/coregrind/m_debuginfo/debuginfo.c +++ b/coregrind/m_debuginfo/debuginfo.c @@ -162,6 +162,8 @@ static inline Bool is_DebugInfo_allocated ( const DebugInfo* di ) // Is this DebugInfo currently "active" (valid for the current epoch) ? static inline Bool is_DebugInfo_active ( const DebugInfo* di ) { + // Temporary workaround for 393146 +#ifndef VGO_darwin if (!is_DiEpoch_INVALID(di->first_epoch) && is_DiEpoch_INVALID(di->last_epoch)) { // Yes it is active. Sanity check .. @@ -170,6 +172,9 @@ static inline Bool is_DebugInfo_active ( const DebugInfo* di ) } else { return False; } +#else + return True; +#endif } // Is this DebugInfo currently "archived" ? -- 2.17.1
I just hit this on x86_64 Linux, so maybe it's not OSX specific.
(In reply to Julian Seward from comment #2) > I just hit this on x86_64 Linux, so maybe it's not OSX specific. Groinch :(. I guess you have no systematic reproducer ? Do you still have the host stacktrace ? The attachment from OSX contains no readable host stack trace.
Running into the same issue on two different macs (one installed via compiling the source, one via brew): https://pastebin.com/BdifEEQ4
Created attachment 114438 [details] valgrind-bug393146-possible-fixes.diff > Running into the same issue on two different macs (one installed via compiling > the source, one via brew): I've been working to fix a number of debuginfo reading problems lately, although on Linux, not OS/X. Try the git trunk, which contains one important fix (e752326cc050803c3bcfde1f8606bead66ff9642) with the attached patch, which contains as-yet uncommitted fixes, on top of it. I don't know if the combination will fix the OS/X debuginfo reading problems, but they do help on Linux.
Thank you! I tried the Git trunk (via Homebrew), but I see the same behaviour as before. I note that in the diff you attached, the line vg_assert(is_DebugInfo_active(di)); is still there.
I also ran into this problem today. I have a GNU/Linux system as well. It doesn't matter if I try the Release or Debug build of my software. For Debug build I use: g++ version 8.2.0 with options -fopenmp -g -std=gnu++1z I tried Valgrind 3.13.0+290+2b0aa0a5-1 as well as git at fee5954ae which seems to include both the commit you mentioned as well as the patch (c263702101, b3fc500a9f). The result is the same. Anything I can do to help fix this problem?
(In reply to Johannes Jordan from comment #7) > Anything I can do to help fix this problem? I think a small compilable reproducer would help. (I however cannot help much, I do not have a MACOS system)
Created attachment 114650 [details] Minimal example that uses Qt QApplication This is a minimal example that triggers the problem on my GNU/Linux system. It is a barebone Qt application. I have Qt 5.11.1 installed on my system. You can either try to use the Makefile directly or run 'qmake minimal-example.pro' to generate one that fits your system. Note that running valgrind on *any* Qt5 application binary on my system triggers this problem. Which is expected given the nature of this minimal example.
(In reply to Johannes Jordan from comment #9) I can confirm I have the same problem with all my Qt5 apps with the most recent version of valgrind. On Arch Linux 4.18.5.
I can confirm William's words - any Qt app on Arch Linux causes this error.
(In reply to Johannes Jordan from comment #9) > Created attachment 114650 [details] > Minimal example that uses Qt QApplication Thanks for the small reproducer. I obtained the same crash on my system. I have committed a fix d457604d498081e402cb223e1a364719dc0c0793. Can you check it is working now on your GNU/linux and on your MACOS systems ? Thanks
(In reply to Philippe Waroquiers from comment #12) > > Can you check it is working now on your GNU/linux and on your MACOS > systems ? Works for me
Works for me as well (Linux, Qt application)
Thank you! The HEAD works for me (MacOSX).
Looks like it can be closed now ...