Valgrind dies at assertion '!overlap' failed

@axel @pcanal This is Ubuntu 20.04 LTS Focal Fossa (development branch) / x86_64 / gcc 9.3.0 and the following simple “trial.cxx” file:

#include "TH1.h"
void trial() { TH1::AddDirectory(kFALSE); }

I face “valgrind” problems for ROOT 6.20/04.

I can run it for “root.exe trial.cxx++O” but it dies for “root.exe trial.cxx++g”:

[...] $ valgrind --suppressions=${ROOTSYS}/etc/valgrind-root.supp root.exe trial.cxx++g
==97416== Memcheck, a memory error detector
==97416== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==97416== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==97416== Command: root.exe trial.cxx++g
  | Welcome to ROOT 6.20/04               |
  | (c) 1995-2020, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on Apr 07 2020, 07:01:00                 |
  | From tag , 1 April 2020                                          |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q'       |

root [0] 
Processing trial.cxx++g...
Info in <TUnixSystem::ACLiC>: creating shared library /..././

valgrind: m_debuginfo/debuginfo.c:916 (truncate_DebugInfoMapping_overlaps): Assertion '!overlap' failed.

host stacktrace:
==97416==    at 0x58046FFA: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==97416==    by 0x58047127: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==97416==    by 0x580472CB: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==97416==    by 0x58079B4D: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==97416==    by 0x580AD60C: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==97416==    by 0x580B9423: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==97416==    by 0x580A8965: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==97416==    by 0x580A4D6A: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==97416==    by 0x580A65A9: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==97416==    by 0x580F5FD4: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)

sched status:

Thread 1: status = VgTs_Runnable syscall 9 (lwpid 97416)
==97416==    at 0x401F0E6: __mmap64 (mmap64.c:59)
==97416==    by 0x401F0E6: mmap (mmap64.c:47)
==97416==    by 0x4007491: _dl_map_segments (dl-map-segments.h:94)
==97416==    by 0x4007491: _dl_map_object_from_fd (dl-load.c:1186)
==97416==    by 0x400A61A: _dl_map_object (dl-load.c:2236)
==97416==    by 0x4015D36: dl_open_worker (dl-open.c:513)
==97416==    by 0x508C727: _dl_catch_exception (dl-error-skeleton.c:208)
==97416==    by 0x40155F9: _dl_open (dl-open.c:837)
==97416==    by 0x52A834B: dlopen_doit (dlopen.c:66)
==97416==    by 0x508C727: _dl_catch_exception (dl-error-skeleton.c:208)
==97416==    by 0x508C7F2: _dl_catch_error (dl-error-skeleton.c:227)
==97416==    by 0x52A8B58: _dlerror_run (dlerror.c:170)
==97416==    by 0x52A83D9: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==97416==    by 0x6235A28: cling::utils::platform::DLOpen(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x61485E2: cling::DynamicLibraryManager::loadLibrary(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, bool) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x614E84B: cling::Interpreter::loadLibrary(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x614EB2F: cling::Interpreter::loadFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, cling::Transaction**) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x621CC18: cling::MetaSema::actOnLCommand(llvm::StringRef, cling::Transaction**) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x622A3DC: cling::MetaParser::isLCommand(cling::MetaSema::ActionResult&) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x622C2F5: cling::MetaParser::isCommand(cling::MetaSema::ActionResult&, cling::Value*) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x6216690: cling::MetaProcessor::process(llvm::StringRef, cling::Interpreter::CompilationResult&, cling::Value*, bool) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x60AE0AB: HandleInterpreterException(cling::MetaProcessor*, char const*, cling::Interpreter::CompilationResult&, cling::Value*) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x60B8393: TCling::Load(char const*, bool) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x4A94B73: TSystem::CompileMacro(char const*, char const*, char const*, char const*, unsigned int)::{lambda(TString const&)#1}::operator()(TString const&) const [clone .isra.0] [clone .constprop.0] (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x4A9D53F: TSystem::CompileMacro(char const*, char const*, char const*, char const*, unsigned int) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x60C571D: TCling::ProcessLine(char const*, TInterpreter::EErrorCode*) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x60C6045: TCling::ProcessLineSynch(char const*, TInterpreter::EErrorCode*) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x4A28B39: TApplication::ExecuteFile(char const*, int*, bool) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x4A29881: TApplication::ProcessLine(char const*, bool, int*) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x485D1B5: TRint::ProcessLineNr(char const*, char const*, int*) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x485EA4C: TRint::Run(bool) (in /.../root_v6.20.04_cxx17_python3/lib/
==97416==    by 0x10917F: main (in /.../root_v6.20.04_cxx17_python3/bin/root.exe)
client stack range: [0x1FFEFF3000 0x1FFF000FFF] client SP: 0x1FFEFFA7C8
valgrind stack range: [0x1002BAA000 0x1002CA9FFF] top usage: 10216 of 1048576

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:

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

Originally, I thought that this problem appeared only when ROOT 6.20/04 was built with “cxx14” or “cxx17” and not with “cxx11”. However, I now rebuilt ROOT as “RelWithDebInfo” (previously it was the default “Release”) and this problem appears in any “cxx1[147]” build (though more complicated macros still survive “valgrind ...++g” in “cxx11” and not in another builds).

I have also tried to run your root_v6.20.04.Linux-ubuntu19-x86_64-gcc9.2.tar.gz binary release on my system and I get the same problem with “valgrind ... trial.cxx++g” (also here, some more complicated macros survive “++g”).

The same problem is shown in (Scientific Linux 7.7, gcc 4.8.5, your root_v6.20.04.Linux-centos7-x86_64-gcc4.8.tar.gz binary release):

Thanks for your bug report !

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.