From: Alexander B. <ale...@lu...> - 2018-09-17 16:42:09
|
Hi, I have a large, complex, non-public project where I used to identify performance issues using callgrind (via QtCreator) but that stopped working. Now I don't get any function names, instead I get "0x00000123456789" or similar. I created a very simple project and it still doesn't work as expected. You can find the project here: https://github.com/abrock/callgrind-test I build it like this: g++ -g main.cpp and run it like this: valgrind --tool=callgrind ./a.out which gives me this output: ==8960== Callgrind, a call-graph generating cache profiler ==8960== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al. ==8960== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==8960== Command: ./a.out ==8960== ==8960== For interactive control, run 'callgrind_control -h'. Hello World! The sum is: 499999500000 The sum is: 49995000 ==8960== ==8960== Events : Ir ==8960== Collected : 14374235 ==8960== ==8960== I refs: 14,374,235 Then I run kcachegrind: kcachegrind callgrind.out.8960 which gives me this result: https://imgur.com/a/anljbAL It shows the two trees for the two functions with different runtimes as expected, but no function names and complains about missing debug symbols and doesn't seem to know the name of the executable. This is my g++ version: g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-6' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.2.0 (Debian 8.2.0-6) I'm out of ideas, did I do something wrong? Feels like I missed something totally obvious. I tried the git version of valgrind which works as expected for the simple test program but crashes for my large project: valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants): Assertion 'cfsi_fits' failed. host stacktrace: ==24946== at 0x58022AB4: show_sched_status_wrk (m_libcassert.c:369) ==24946== by 0x58022BC7: report_and_quit (m_libcassert.c:440) ==24946== by 0x58022D59: vgPlain_assert_fail (m_libcassert.c:506) ==24946== by 0x58049F7F: vgPlain_di_notify_mmap (debuginfo.c:738) ==24946== by 0x5807A96B: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2402) ==24946== by 0x5808640F: vgSysWrap_amd64_linux_sys_mmap_before (syswrap-amd64-linux.c:404) ==24946== by 0x58076081: vgPlain_client_syscall (syswrap-main.c:1863) ==24946== by 0x58072C1A: handle_syscall (scheduler.c:1176) ==24946== by 0x580744D6: vgPlain_scheduler (scheduler.c:1498) ==24946== by 0x580D5330: run_a_thread_NORETURN (syswrap-linux.c:103) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 9 (lwpid 24946) ==24946== at 0x401A693: mmap (mmap64.c:52) ==24946== by 0x40060AD: _dl_map_object_from_fd (dl-map-segments.h:94) ==24946== by 0x400890E: _dl_map_object (dl-load.c:2461) ==24946== by 0x400D061: openaux (dl-deps.c:63) ==24946== by 0x401950A: _dl_catch_exception (dl-error-skeleton.c:196) ==24946== by 0x400D2F2: _dl_map_object_deps (dl-deps.c:249) ==24946== by 0x4003D95: dl_main (rtld.c:1726) ==24946== by 0x401862F: _dl_sysdep_start (dl-sysdep.c:253) ==24946== by 0x40020D7: _dl_start (rtld.c:414) ==24946== by 0x4001217: ??? (in /lib/x86_64-linux-gnu/ld-2.27.so) client stack range: [0x1FFEFFE000 0x1FFF000FFF] client SP: 0x1FFEFFE258 valgrind stack range: [0x1002A8E000 0x1002B8DFFF] top usage: 16248 of 1048576 Best Regards, Alexander |
From: Julian S. <js...@ac...> - 2018-09-17 17:27:04
|
On 17/09/18 18:15, Alexander Brock wrote: > valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants): > Assertion 'cfsi_fits' failed. Is that really still failing? I thought that got comprehensively fixed in the past few weeks. Can you re-try? J |
From: Alexander B. <ale...@lu...> - 2018-09-17 20:14:45
|
On 9/17/18 7:26 PM, Julian Seward wrote: >> valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants): >> Assertion 'cfsi_fits' failed. > > Is that really still failing? I thought that got comprehensively fixed > in the past few weeks. Can you re-try? I ran "git pull" (no new commits, latest commit is 97365bada64c27a40004c55793ff8988e59adf35) and re-tried with a couple of executables in my project, each fail: http://paste.debian.net/1043013/ It doesn't matter if I use callgrind or memcheck, here is the output for memcheck: http://paste.debian.net/1043014/ Alexander |
From: Philippe W. <phi...@sk...> - 2018-09-17 21:31:31
|
On Mon, 2018-09-17 at 22:14 +0200, Alexander Brock wrote: > On 9/17/18 7:26 PM, Julian Seward wrote: > > > valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants): > > > Assertion 'cfsi_fits' failed. > > > > Is that really still failing? I thought that got comprehensively fixed > > in the past few weeks. Can you re-try? We had a problem with all Qt applications, failing with Bug 393146 - failing assert "is_DebugInfo_active(di)" which is (I believe) fully fixed. However, this cfsi_fits failing looks to be something different, i.e. the (not yet fixed) bug : Bug 398028 - Assertion `csfi_fits` failing in simple C program with embedded Julia code. (I guess it might be related to using a newer gcc, or a newer glibc, or something else new, seeing the versions reported). If you have a small reproducer, you might look at the last comment of the bug https://bugs.kde.org/show_bug.cgi?id=398028 and attach the traces with the suggested debug switches. That might help to see (guess) what is wrong. Thanks Philippe > > I ran "git pull" (no new commits, latest commit is > 97365bada64c27a40004c55793ff8988e59adf35) and re-tried with a couple of > executables in my project, each fail: > > http://paste.debian.net/1043013/ > > It doesn't matter if I use callgrind or memcheck, here is the output for > memcheck: > > http://paste.debian.net/1043014/ > > Alexander > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
From: Alexander B. <ale...@lu...> - 2018-09-18 19:57:04
|
On 9/17/18 11:31 PM, Philippe Waroquiers wrote: > If you have a small reproducer, you might look at the last comment > of the bug https://bugs.kde.org/show_bug.cgi?id=398028 > and attach the traces with the suggested debug switches. The smallest reproducer I could come up with is a cpp file with only a main function linked to openblas. I tried to stuff all relevant information in the comments to the bug report, does it reproduce? Alexander |