Valgrind doesn't start for me, I do not know why. It does not react to Ctrl+C, I only can kill it with `kill -9 PID`. Trying to debug it a bit, I get the following backtrace. I tried to run evolution and gnome-calendar as: $ G_SLICE=always-malloc valgrind --leak-check=no --vgdb=full --vgdb-error=0 gnome-calendar This is with valgrind-3.19.0-4.fc37.x86_64, but also with valgrind-3.19.0-3.fc36.x86_64. (gdb) t a a bt Thread 1 (Thread 2728 (tid 1 VgTs_Runnable)): #0 __mmap64 (offset=0, fd=-1, flags=50, prot=3, len=109456, addr=0x8e28000) at ../sysdeps/unix/sysv/linux/mmap64.c:58 #1 __mmap64 (addr=0x8e28000, len=109456, prot=3, flags=50, fd=-1, offset=0) at ../sysdeps/unix/sysv/linux/mmap64.c:46 #2 0x0000000004007cfb in _dl_map_segments (loader=0x1ffefff030, has_holes=<optimized out>, maplength=<optimized out>, nloadcmds=<optimized out>, loadcmds=<optimized out>, type=<optimized out>, header=0x40000000b, fd=<optimized out>, l=0x5ad2fe0) at ./dl-map-segments.h:186 #3 _dl_map_object_from_fd (name=name@entry=0x485e8ac "libwebkit2gtk-4.1.so.0", origname=origname@entry=0x0, fd=<optimized out>, fbp=fbp@entry=0x1ffefff0d0, realname=<optimized out>, loader=loader@entry=0x4836af0, l_type=<optimized out>, mode=<optimized out>, stack_endp=<optimized out>, nsid=<optimized out>) at dl-load.c:1268 #4 0x00000000040085b5 in _dl_map_object (loader=<optimized out>, name=0x485e8ac "libwebkit2gtk-4.1.so.0", type=1, trace_mode=<optimized out>, mode=0, nsid=<optimized out>) at dl-load.c:2253 #5 0x0000000004002335 in openaux (a=a@entry=0x1ffefff830) at dl-deps.c:64 #6 0x0000000004018dc9 in _dl_catch_exception (exception=exception@entry=0x1ffefff810, operate=operate@entry=0x4002300 <openaux>, args=args@entry=0x1ffefff830) at /usr/src/debug/glibc-2.36-3.fc37.x86_64/elf/dl-error-skeleton.c:208 #7 0x0000000004002788 in _dl_map_object_deps (map=map@entry=0x40352c0, preloads=preloads@entry=0x1ffefffcb0, npreloads=<optimized out>, trace_mode=<optimized out>, open_mode=open_mode@entry=0) at dl-deps.c:232 #8 0x000000000401e61b in dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:1980 #9 0x000000000401aeb3 in _dl_sysdep_start (start_argptr=start_argptr@entry=0x1fff000080, dl_main=dl_main@entry=0x401cba0 <dl_main>) at ../sysdeps/unix/sysv/linux/dl-sysdep.c:140 #10 0x000000000401c89c in _dl_start_final (arg=0x1fff000080) at rtld.c:497 #11 _dl_start (arg=<optimized out>) at rtld.c:584 #12 0x000000000401b6d8 in _dl_start_user () at /lib64/ld-linux-x86-64.so.2 #13 0x0000000000000001 in () #14 0x0000001fff000367 in () #15 0x0000000000000000 in () (gdb) f 6 #6 0x0000000004018dc9 in _dl_catch_exception (exception=exception@entry=0x1ffefff810, operate=operate@entry=0x4002300 <openaux>, args=args@entry=0x1ffefff830) at /usr/src/debug/glibc-2.36-3.fc37.x86_64/elf/dl-error-skeleton.c:208 Downloading 0.00 MB source file /usr/src/debug/glibc-2.36-3.fc37.x86_64/elf/dl-error-skeleton.c 208 (*operate) (args); (gdb) p *exception $1 = {objname = 0x0, errstring = 0x0, message_buffer = 0x0} (gdb) q
I cannot replicate this with: valgrind-3.20.0-1.fc37.x86_64 gnome-calendar-43.1-3.fc37.x86_64 It takes a while for the calendar to show, but it does show up eventually. Do you have DEBUGINFOD_URLS set? (The default on fedora 37) gnome-calendar links to a lot of libraries and with DEBUGINFOD_URLS set valgrind will try to fetch debuginfo for all of them. Maybe network is slow? Try unset DEBUGINFOD_URLS to see if that makes startup faster.
The gnome-calendar is stuck on start even with unset DEBUGINFOD_URLS. I tried with the same versions as you. There is no CPU use, no network use, no GUI shown.
This is really odd. I don't know why I am not seeing the issue. So looking at your stacktrace it seems the process is stuck in an mmap call trying to load libwebkit2gtk. I don't have any good theory why/how that is happening. Is the backtrace always the same when the valgrind seems stuck?
Aha, you are right, it's not stuck, it's only that slow (even with disabled debuginfo url). It takes several minutes to start here, with no significant CPU usage (which I consider as a usual indication that valgrind is doing something). I'm sorry for a false report.
(In reply to Milan Crha from comment #4) > Aha, you are right, it's not stuck, it's only that slow (even with disabled > debuginfo url). It takes several minutes to start here, with no significant > CPU usage (which I consider as a usual indication that valgrind is doing > something). I'm sorry for a false report. No worries. And thanks for the extra testing. It is good to get reports when something is odd. My apologies it took so long to respond. It is still somewhat odd. It does take a long time to start up here, ~25 seconds with DEBUGINFOD_URLS unset, ~60 seconds with all debuginfo already available and more than a minute if all debuginfo has to be downloaded first (valgrind needs to learn how to do that much more lazily, most isn't really needed, and provide some feedback if it is doing that).