|
From: Alvaro K. <ku...@gm...> - 2021-09-05 23:30:01
|
Hello everyone! I am running valgrind on my PC with dual boot Windows 10 and Fedora 34. Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind runs in less than a second, but on Fedora 34 is very slow, several minutes slow. On Fedora 34 it looks like the time spent is reading symbols. This is the part that takes most of the time: --23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29 --23524-- Considering /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug .. --23524-- .. build-id is valid --23524-- Considering /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64 .. --23524-- .. build-id is valid --23524-- Reading syms from /usr/lib64/libm-2.33.so --23524-- Considering /usr/lib/debug/.build-id/c1/784bbe8a93a6e62f74b16105a2076a03b398ac.debug .. --23524-- .. build-id is valid --23524-- Reading syms from /usr/lib64/libgcc_s-11-20210728.so.1 --23524-- Considering /usr/lib/debug/.build-id/46/e10c9ee769c5cfc7cdb638e3ccbc3169c0a949.debug .. --23524-- .. build-id is valid --23524-- Considering /usr/lib/debug/.build-id/46/../../../../../usr/lib/debug/lib64/../.dwz/gcc-11.2.1-1.fc34.x86_64 .. --23524-- .. build-id is valid --23524-- Reading syms from /usr/lib64/libc-2.33.so --23524-- Considering /usr/lib/debug/.build-id/9d/e0f6e78ec16db4c6c167efc6b37466705edeff.debug .. --23524-- .. build-id is valid --23524-- Considering /usr/lib/debug/.build-id/9d/../../../../../usr/lib/debug/lib64/../.dwz/glibc-2.33-20.fc34.x86_64 .. --23524-- .. build-id is valid What could be the problem? GGC 11 perhaps? Thanks! |
|
From: Alvaro K. <ku...@gm...> - 2021-09-06 01:30:29
|
This is using valgrind compiled from GIT sources using my test program: [alvarok@YELLOWJACKET tarea5]$ valgrind -v ./principal ==45395== Memcheck, a memory error detector ==45395== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==45395== Using Valgrind-3.18.0.GIT-1bee3ab757-20210901 and LibVEX; rerun with -h for copyright info ==45395== Command: ./principal ==45395== --45395-- Valgrind options: --45395-- -v --45395-- Contents of /proc/version: --45395-- Linux version 5.13.13-200.fc34.x86_64 ( moc...@bk...) (gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1), GNU ld version 2.35.2-5.fc34) #1 SMP Thu Aug 26 17:06:39 UTC 2021 --45395-- --45395-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed --45395-- Page sizes: currently 4096, max supported 4096 --45395-- Valgrind library directory: /usr/local/libexec/valgrind --45395-- Reading syms from /home/alvarok/Development/Skills/Prog2/Laboratorio/Tarea5/tarea5/principal --45395-- Reading syms from /usr/lib64/ld-2.33.so --45395-- Warning: cross-CU LIMITATION: some inlined fn names --45395-- might be shown as UnknownInlinedFun --45395-- Reading syms from /usr/local/libexec/valgrind/memcheck-amd64-linux --45395-- object doesn't have a dynamic symbol table --45395-- Scheduler: using generic scheduler lock implementation. --45395-- Reading suppressions file: /usr/local/libexec/valgrind/default.supp ==45395== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-45395-by-alvarok-on-YELLOWJACKET ==45395== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-45395-by-alvarok-on-YELLOWJACKET ==45395== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-45395-by-alvarok-on-YELLOWJACKET ==45395== ==45395== TO CONTROL THIS PROCESS USING vgdb (which you probably ==45395== don't want to do, unless you know exactly what you're doing, ==45395== or are doing some strange experiment): ==45395== /usr/local/libexec/valgrind/../../bin/vgdb --pid=45395 ...command... ==45395== ==45395== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==45395== /path/to/gdb ./principal ==45395== and then give GDB the following command ==45395== target remote | /usr/local/libexec/valgrind/../../bin/vgdb --pid=45395 ==45395== --pid is optional if only one valgrind process is running ==45395== --45395-- REDIR: 0x4025130 (ld-linux-x86-64.so.2:strlen) redirected to 0x580b31e2 (vgPlain_amd64_linux_REDIR_FOR_strlen) --45395-- REDIR: 0x4024f00 (ld-linux-x86-64.so.2:index) redirected to 0x580b31fc (vgPlain_amd64_linux_REDIR_FOR_index) --45395-- Reading syms from /usr/local/libexec/valgrind/vgpreload_core-amd64-linux.so --45395-- Reading syms from /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-linux.so ==45395== WARNING: new redirection conflicts with existing -- ignoring it --45395-- old: 0x04025130 (strlen ) R-> (0000.0) 0x580b31e2 vgPlain_amd64_linux_REDIR_FOR_strlen --45395-- new: 0x04025130 (strlen ) R-> (2007.0) 0x048463c0 strlen --45395-- REDIR: 0x4021910 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4847220 (strcmp) --45395-- REDIR: 0x4025690 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x484ac90 (mempcpy) --45395-- Reading syms from /usr/lib64/libstdc++.so.6.0.29 --45395-- Considering /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug .. --45395-- .. build-id is valid --45395-- Considering /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64 .. --45395-- .. build-id is valid --45395-- Reading syms from /usr/lib64/libm-2.33.so --45395-- Considering /usr/lib/debug/.build-id/c1/784bbe8a93a6e62f74b16105a2076a03b398ac.debug .. --45395-- .. build-id is valid --45395-- Reading syms from /usr/lib64/libgcc_s-11-20210728.so.1 --45395-- Considering /usr/lib/debug/.build-id/46/e10c9ee769c5cfc7cdb638e3ccbc3169c0a949.debug .. --45395-- .. build-id is valid --45395-- Considering /usr/lib/debug/.build-id/46/../../../../../usr/lib/debug/lib64/../.dwz/gcc-11.2.1-1.fc34.x86_64 .. --45395-- .. build-id is valid --45395-- Reading syms from /usr/lib64/libc-2.33.so --45395-- Considering /usr/lib/debug/.build-id/9d/e0f6e78ec16db4c6c167efc6b37466705edeff.debug .. --45395-- .. build-id is valid --45395-- Considering /usr/lib/debug/.build-id/9d/../../../../../usr/lib/debug/lib64/../.dwz/glibc-2.33-20.fc34.x86_64 .. --45395-- .. build-id is valid --45395-- REDIR: 0x4c6eee0 (libc.so.6:memmove) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) ==45395== Preferring higher priority redirection: --45395-- old: 0x04d41710 (__memcpy_avx_unalign) R-> (2018.0) 0x04848470 __memcpy_avx_unaligned_erms --45395-- new: 0x04d41710 (__memcpy_avx_unalign) R-> (2018.1) 0x04849d10 memmove --45395-- REDIR: 0x4c6e3e0 (libc.so.6:strncpy) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6f220 (libc.so.6:strcasecmp) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6de90 (libc.so.6:strcat) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6e440 (libc.so.6:rindex) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c705d0 (libc.so.6:rawmemchr) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c88680 (libc.so.6:wmemchr) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c881c0 (libc.so.6:wcscmp) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6f040 (libc.so.6:mempcpy) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6ee70 (libc.so.6:bcmp) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6e380 (libc.so.6:strncmp) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6df40 (libc.so.6:strcmp) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6efb0 (libc.so.6:memset) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c88180 (libc.so.6:wcschr) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6e2e0 (libc.so.6:strnlen) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6e020 (libc.so.6:strcspn) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6f270 (libc.so.6:strncasecmp) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6dfc0 (libc.so.6:strcpy) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6f3c0 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c898d0 (libc.so.6:wcsnlen) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c88200 (libc.so.6:wcscpy) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6e480 (libc.so.6:strpbrk) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6def0 (libc.so.6:index) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6e2a0 (libc.so.6:strlen) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c74a80 (libc.so.6:memrchr) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6f2c0 (libc.so.6:strcasecmp_l) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6ee30 (libc.so.6:memchr) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c882d0 (libc.so.6:wcslen) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6e5a0 (libc.so.6:strspn) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6f1c0 (libc.so.6:stpncpy) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6f160 (libc.so.6:stpcpy) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c70610 (libc.so.6:strchrnul) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4c6f310 (libc.so.6:strncasecmp_l) redirected to 0x48351b6 (_vgnU_ifunc_wrapper) --45395-- REDIR: 0x4d3e530 (libc.so.6:__strrchr_avx2) redirected to 0x4845e00 (rindex) --45395-- REDIR: 0x4c6a100 (libc.so.6:malloc) redirected to 0x4840739 (malloc) --45395-- REDIR: 0x490da50 (libstdc++.so.6:operator new(unsigned long)) redirected to 0x4840ea3 (operator new(unsigned long)) --45395-- REDIR: 0x490dab0 (libstdc++.so.6:operator new[](unsigned long)) redirected to 0x4842095 (operator new[](unsigned long)) --45395-- REDIR: 0x4d3e340 (libc.so.6:__strchrnul_avx2) redirected to 0x484a790 (strchrnul) --45395-- REDIR: 0x4d416f0 (libc.so.6:__mempcpy_avx_unaligned_erms) redirected to 0x484a8a0 (mempcpy) 1>Fin --45395-- REDIR: 0x4d39bf0 (libc.so.6:__strcmp_avx2) redirected to 0x4847120 (strcmp) --45395-- REDIR: 0x4d3e700 (libc.so.6:__strlen_avx2) redirected to 0x48462a0 (strlen) Fin. --45395-- REDIR: 0x4d3a560 (libc.so.6:__memchr_avx2) redirected to 0x48472a0 (memchr) --45395-- REDIR: 0x4d41710 (libc.so.6:__memcpy_avx_unaligned_erms) redirected to 0x4849d10 (memmove) --45395-- REDIR: 0x490bd00 (libstdc++.so.6:operator delete(void*, unsigned long)) redirected to 0x48436d3 (operator delete(void*, unsigned long)) --45395-- REDIR: 0x490bd20 (libstdc++.so.6:operator delete[](void*)) redirected to 0x48443f9 (operator delete[](void*)) --45395-- REDIR: 0x4c6a760 (libc.so.6:free) redirected to 0x4842f0e (free) ==45395== ==45395== HEAP SUMMARY: ==45395== in use at exit: 0 bytes in 0 blocks ==45395== total heap usage: 23 allocs, 23 frees, 75,192 bytes allocated ==45395== ==45395== All heap blocks were freed -- no leaks are possible ==45395== ==45395== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) On Sun, Sep 5, 2021 at 8:29 PM Alvaro Kuolas <ku...@gm...> wrote: > Hello everyone! > > I am running valgrind on my PC with dual boot Windows 10 and Fedora 34. > > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind > runs in less than a second, but on Fedora 34 is very slow, several minutes > slow. > > On Fedora 34 it looks like the time spent is reading symbols. > > This is the part that takes most of the time: > > --23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29 > --23524-- Considering > /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug .. > --23524-- .. build-id is valid > --23524-- Considering > /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64 > .. > --23524-- .. build-id is valid > --23524-- Reading syms from /usr/lib64/libm-2.33.so > --23524-- Considering > /usr/lib/debug/.build-id/c1/784bbe8a93a6e62f74b16105a2076a03b398ac.debug .. > --23524-- .. build-id is valid > --23524-- Reading syms from /usr/lib64/libgcc_s-11-20210728.so.1 > --23524-- Considering > /usr/lib/debug/.build-id/46/e10c9ee769c5cfc7cdb638e3ccbc3169c0a949.debug .. > --23524-- .. build-id is valid > --23524-- Considering > /usr/lib/debug/.build-id/46/../../../../../usr/lib/debug/lib64/../.dwz/gcc-11.2.1-1.fc34.x86_64 > .. > --23524-- .. build-id is valid > --23524-- Reading syms from /usr/lib64/libc-2.33.so > --23524-- Considering > /usr/lib/debug/.build-id/9d/e0f6e78ec16db4c6c167efc6b37466705edeff.debug .. > --23524-- .. build-id is valid > --23524-- Considering > /usr/lib/debug/.build-id/9d/../../../../../usr/lib/debug/lib64/../.dwz/glibc-2.33-20.fc34.x86_64 > .. > --23524-- .. build-id is valid > > What could be the problem? GGC 11 perhaps? > > Thanks! > |
|
From: John R. <jr...@bi...> - 2021-09-06 01:58:29
|
> I am running valgrind on my PC with dual boot Windows 10 and Fedora 34. > > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind runs in less than a second, but on Fedora 34 is very slow, several minutes slow. > > On Fedora 34 it looks like the time spent is reading symbols. > > This is the part that takes most of the time: > > --23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29 > --23524-- Considering /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug .. > --23524-- .. build-id is valid > --23524-- Considering /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64 .. > --23524-- .. build-id is valid [[snip]] > > What could be the problem? GGC 11 perhaps? There have been some hints of trouble with the DWARF-5 symbol reader. Thus a work-around might be to avoid DWARF-5 by using an older gcc. If you can, please run "perf record" and then "perf report", and copy+paste (or attach) info into a Bug Report (see https://valgrind.org). Then post the bug link here with a teaser. |
|
From: Alvaro K. <ku...@gm...> - 2021-09-06 02:36:10
|
I opened a bug report https://bugs.kde.org/show_bug.cgi?id=442061 I have attached perf-record data Thanks for your help! On Sun, Sep 5, 2021 at 10:59 PM John Reiser <jr...@bi...> wrote: > > I am running valgrind on my PC with dual boot Windows 10 and Fedora 34. > > > > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind > runs in less than a second, but on Fedora 34 is very slow, several minutes > slow. > > > > On Fedora 34 it looks like the time spent is reading symbols. > > > > This is the part that takes most of the time: > > > > --23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29 > > --23524-- Considering > /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug .. > > --23524-- .. build-id is valid > > --23524-- Considering > /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64 > .. > > --23524-- .. build-id is valid > [[snip]] > > > > What could be the problem? GGC 11 perhaps? > > There have been some hints of trouble with the DWARF-5 symbol reader. > Thus a work-around might be to avoid DWARF-5 by using an older gcc. > > If you can, please run "perf record" and then "perf report", > and copy+paste (or attach) info into a Bug Report (see > https://valgrind.org). > Then post the bug link here with a teaser. > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: John B. <all...@gm...> - 2021-09-06 02:23:02
|
if you have a lot of threads you can try the fair scheduler flag. On Sun, Sep 5, 2021, 8:59 PM John Reiser <jr...@bi...> wrote: > > I am running valgrind on my PC with dual boot Windows 10 and Fedora 34. > > > > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind > runs in less than a second, but on Fedora 34 is very slow, several minutes > slow. > > > > On Fedora 34 it looks like the time spent is reading symbols. > > > > This is the part that takes most of the time: > > > > --23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29 > > --23524-- Considering > /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug .. > > --23524-- .. build-id is valid > > --23524-- Considering > /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64 > .. > > --23524-- .. build-id is valid > [[snip]] > > > > What could be the problem? GGC 11 perhaps? > > There have been some hints of trouble with the DWARF-5 symbol reader. > Thus a work-around might be to avoid DWARF-5 by using an older gcc. > > If you can, please run "perf record" and then "perf report", > and copy+paste (or attach) info into a Bug Report (see > https://valgrind.org). > Then post the bug link here with a teaser. > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Alvaro K. <ku...@gm...> - 2021-09-06 02:39:31
|
My program is very simple: they are exercises from a course about ADT (Abstract Data Types). On Sun, Sep 5, 2021 at 11:24 PM John Borland < all...@gm...> wrote: > if you have a lot of threads you can try the fair scheduler flag. > > On Sun, Sep 5, 2021, 8:59 PM John Reiser <jr...@bi...> wrote: > >> > I am running valgrind on my PC with dual boot Windows 10 and Fedora 34. >> > >> > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind >> runs in less than a second, but on Fedora 34 is very slow, several minutes >> slow. >> > >> > On Fedora 34 it looks like the time spent is reading symbols. >> > >> > This is the part that takes most of the time: >> > >> > --23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29 >> > --23524-- Considering >> /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug .. >> > --23524-- .. build-id is valid >> > --23524-- Considering >> /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64 >> .. >> > --23524-- .. build-id is valid >> [[snip]] >> > >> > What could be the problem? GGC 11 perhaps? >> >> There have been some hints of trouble with the DWARF-5 symbol reader. >> Thus a work-around might be to avoid DWARF-5 by using an older gcc. >> >> If you can, please run "perf record" and then "perf report", >> and copy+paste (or attach) info into a Bug Report (see >> https://valgrind.org). >> Then post the bug link here with a teaser. >> >> >> >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Mark W. <ma...@kl...> - 2021-09-06 12:03:13
|
Hi, On Sun, 2021-09-05 at 20:29 -0300, Alvaro Kuolas wrote: > I am running valgrind on my PC with dual boot Windows 10 and Fedora > 34. > > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) > valgrind runs > in less than a second, but on Fedora 34 is very slow, several minutes > slow. > > On Fedora 34 it looks like the time spent is reading symbols. Do you have lots of debuginfo packages installed or is the DEBUGINFOD_URLS set? See https://fedoraproject.org/wiki/Debuginfod valgrind is fairly slow parsing all the DWARF information. But will happily use debuginfod to fetch more or use all debuginfo packages installed for any library you have installed. In your case it might be help unsetting DEBUGINFOD_URLS and looking trough the list of installed debuginfo packages and uninstall some (if I read your log it is probably libstdc++-debuginfo that takes a lot of time to parse. Cheers, Mark |
|
From: Alvaro K. <ku...@gm...> - 2021-09-06 12:25:20
|
Yes, I installed debuginfo to try gdb reverse-step. The packages installed where: debuginfo-install glibc-2.33-20.fc34.x86_64 libgcc-11.2.1-1.fc34.x86_64 libstdc++-11.2.1-1.fc34.x86_64 On Mon, Sep 6, 2021 at 8:37 AM Mark Wielaard <ma...@kl...> wrote: > Hi, > > On Sun, 2021-09-05 at 20:29 -0300, Alvaro Kuolas wrote: > > I am running valgrind on my PC with dual boot Windows 10 and Fedora > > 34. > > > > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) > > valgrind runs > > in less than a second, but on Fedora 34 is very slow, several minutes > > slow. > > > > On Fedora 34 it looks like the time spent is reading symbols. > > Do you have lots of debuginfo packages installed or is the > DEBUGINFOD_URLS set? See https://fedoraproject.org/wiki/Debuginfod > > valgrind is fairly slow parsing all the DWARF information. But will > happily use debuginfod to fetch more or use all debuginfo packages > installed for any library you have installed. > > In your case it might be help unsetting DEBUGINFOD_URLS and looking > trough the list of installed debuginfo packages and uninstall some (if > I read your log it is probably libstdc++-debuginfo that takes a lot of > time to parse. > > Cheers, > > Mark > |