I'm not smart enough to know whether this is a bug with valgrind or with glfw so I'm posting it on both bug trackers... hopefully someone in one of those places will know what's going on ([GLFW thread](https://github.com/glfw/glfw/issues/1156)). I'm using CLion 2017.3's new Valgrind Memcheck integration. I'm on macOS High Sierra 10.13.1. Compiled valgrind from [valgrind master](http://valgrind.org/downloads/repository.html) @ `1ce04c35c2ebbc8ea3c2b38ba69daa9dd40cde35` (preliminary Darwin support, as suggested in [this thread](https://bugs.kde.org/show_bug.cgi?id=383811)). I've reduced my code to: ```c++ #define GLFW_INCLUDE_NONE #include <GLFW/glfw3.h> int main() { glfwInit(); // valgrind crashes } ``` This is my output: ```bash /path/to/bin/valgrind --tool=memcheck --xml=yes --xml-file=/private/var/folders/lf/11gl5cgn14s9lyn933tg134m0000gq/T/valgrind --gen-suppressions=all --leak-check=full --leak-resolution=med --track-origins=yes /path/to/my/executable --15650-- run: /usr/bin/dsymutil "/path/to/my/executable" --15650-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option --15650-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times) --15650-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times) ==15650== valgrind: Unrecognised instruction at address 0x1062a2ecf. ==15650== Your program just tried to execute an instruction that Valgrind ==15650== did not recognise. There are two possible reasons for this. ==15650== 1. Your program has a bug and erroneously jumped to a non-code ==15650== location. If you are running Memcheck and you just saw a ==15650== warning about a bad jump, it's probably your program's fault. ==15650== 2. The instruction is legitimate but Valgrind doesn't handle it, ==15650== i.e. it's Valgrind's fault. If you think this is the case or ==15650== you are not sure, please let us know and we'll try to fix it. ==15650== Either way, Valgrind will now raise a SIGILL signal which will ==15650== probably kill your program. Process finished with exit code 4 ```
I get slightly different results when running the same command from the terminal instead of via CLion: ```bash --15943-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option --15943-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times) --15943-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times) --15943-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times) eq_SyscallStatus: {78 0 43} {78 0 40} valgrind: m_syswrap/syswrap-main.c:438 (Bool eq_SyscallStatus(UInt, SyscallStatus *, SyscallStatus *)): the 'impossible' happened. host stacktrace: ==15943== at 0x258052B8B: ??? ==15943== by 0x258052F1C: ??? ==15943== by 0x258052EF3: ??? ==15943== by 0x2580EC414: ??? ==15943== by 0x2580EB9F9: ??? ==15943== by 0x2580E9C20: ??? ==15943== by 0x2580E83E0: ??? ==15943== by 0x2580FA29E: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 771) 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: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. ```
Hi Ben, Thanks for the bug report and simple reproduction case. Based on the error reports, this looks a lot like a duplicate of a known issue bz#385279. Whilst we haven't quite landed a fix for that one in the development code base - there is a patch with a potential resolution on the linked bug report. If you're able to, testing that patch with your test case would be really helpful. Note that fixing this one issue might expose latter ones -- but at least we will establish whether this initial reported bug is fixed with bz#385279 *** This bug has been marked as a duplicate of bug 385279 ***
Hey Rhys, thanks for the patch - I applied it and rebuilt (autogen, configure, make, make install). Unfortunately it does not change anything for me. I get the same error output when I run valgrind memcheck. Were you able to repro my issue on your end? I should note that the two error logs I supplied were apparently related to different issues. The first (from CLion) is when the program is successful until hitting glfwInit(). Any calls to `std::cout << str << "\n";` prior to the bailout are successful. Whereas when I run the same command from the terminal my program appears to not even start (and I get the second error log). Since I'm totally new to valgrind I may have missed a flag specification that works differently between CLion and the default bash environment. I totally copied the flags from CLion and didn't add any on my own.
I'm remarking this as 'UNCONFIRMED' since the provided patch didn't work for me. Could someone please follow up? Thanks.