Simply calling the GLib g_get_user_special_dir() function on a Mac OS 10.11.1 system seemingly causes Valgrind to enter an infinite loop using 100% CPU. ``` #include <glib.h> #include <stdlib.h> int main() { g_get_user_special_dir(G_USER_DIRECTORY_DOCUMENTS); return EXIT_SUCCESS; } ``` Compiled with: cc -g -o get_user_special_dir.bin `pkg-config --cflags glib-2.0` get_user_special_dir.c `pkg-config --libs glib-2.0` Ran with: valgrind ./get_user_special_dir.bin Trimmed output: ``` ==4088== Memcheck, a memory error detector ==4088== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==4088== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==4088== Command: ./get_user_special_dir.bin ==4088== ==4088== Conditional jump or move depends on uninitialised value(s) ==4088== at 0x7FFF5FC24A27: bcmp (in /usr/lib/dyld) ... ==4088== ==4088== Use of uninitialised value of size 8 ==4088== at 0x7FFF5FC24A3F: bcmp (in /usr/lib/dyld) ... ==4088== ==4088== Use of uninitialised value of size 8 ==4088== at 0x7FFF5FC24A44: bcmp (in /usr/lib/dyld) ... ==4088== ==4088== Conditional jump or move depends on uninitialised value(s) ==4088== at 0x7FFF5FC11907: ImageLoaderMachO::validateFirstPages(linkedit_data_command const*, int, unsigned char const*, unsigned long, long long, ImageLoader::LinkContext const&) (in /usr/lib/dyld) ... ==4088== --4088-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option --4088-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times) --4088-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times) --4088-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times) Killed: 9 ``` (I had to force-quit valgrind.) Using: - GLib 2.46.2 (installed via Homebrew 'el_capitan' bottle) - Valgrind 3.11.0 (also installed via Homebrew 'el_capitan' bottle) I tried the above on an Ubuntu 14.04.3 LTS 'Trusty Tahr' system with Valgrind 3.10.0, but did not observe the 100% CPU utilization problem. Reproducible: Always Steps to Reproduce: 1. Install the pkg-config, glib, and valgrind Homebrew packages. 2. Save the following as get_user_special_dir.c: ``` #include <glib.h> #include <stdlib.h> int main() { g_get_user_special_dir(G_USER_DIRECTORY_DOCUMENTS); return EXIT_SUCCESS; } ``` 3. Compile get_user_special_dir.c via: cc -g -o get_user_special_dir.bin `pkg-config --cflags glib-2.0` get_user_special_dir.c `pkg-config --libs glib-2.0` 4. Run via: valgrind ./get_user_special_dir.bin 5. After a few seconds, open the Activity Monitor app and observe that the valgrind process is utilizing 100% CPU. Actual Results: 100% CPU utilization and valgrind seems like it would never finish (I'm not sure because I kill the process each time after a few minutes). Expected Results: valgrind should run and complete. Using: - GLib 2.46.2 (installed via Homebrew 'el_capitan' bottle) - Valgrind 3.11.0 (also installed via Homebrew 'el_capitan' bottle) I tried the above on an Ubuntu 14.04.3 LTS 'Trusty Tahr' system with Valgrind 3.10.0, but did not observe the 100% CPU utilization problem.
I have just tried out Valgrind at revision 15740 (valgrind-3.12.0.SVN) and see the issue.
I came here because I was seeing a similar issue on my machine. However, I cannot reproduce the result with your example program. I get the following output: ``` ... ==47690== --47690-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option --47690-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times) --47690-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times) --47690-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times) --47690-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 16 times) ==47690== ==47690== HEAP SUMMARY: ==47690== in use at exit: 762,521 bytes in 1,079 blocks ==47690== total heap usage: 2,024 allocs, 945 frees, 1,391,817 bytes allocated ==47690== ==47690== LEAK SUMMARY: ==47690== definitely lost: 6,808 bytes in 44 blocks ==47690== indirectly lost: 8,910 bytes in 74 blocks ==47690== possibly lost: 5,944 bytes in 126 blocks ==47690== still reachable: 95,268 bytes in 476 blocks ==47690== suppressed: 645,591 bytes in 359 blocks ==47690== Rerun with --leak-check=full to see details of leaked memory ==47690== ==47690== For counts of detected and suppressed errors, rerun with: -v ==47690== Use --track-origins=yes to see where uninitialised values come from ==47690== ERROR SUMMARY: 20 errors from 4 contexts (suppressed: 2 from 1) ``` I use MacPorts. Valgrind version is valgrind-devel @3.12.0-r15708_0 (I have applied a small patch to set the magic_delta correct for El Capitan, see here: https://bugs.kde.org/show_bug.cgi?id=354883).
Me too. You can test this on a simple default QtQuick Application on Qt framework. Platform specifications: Mac OS 10.11.3 - Valgrind 3.11.0 - Qt 5.6.0
I get this hang as well, using 3.13.0SVN and El Capitan 10.11.6. I tested with d2x-rebirth using: valgrind --leak-check=yes /Users/XXXXX/Programming/dxx-rebirth/build/d2x-rebirth-opengl/D2X-Rebirth.app/Contents/MacOS/d2x-rebirth-editor