5

I am trying to use Callgrind to monitor cache usage in an SDL2 application, but it hangs on the SDL_Init call - EDIT: To clarify, Valgrind hangs, there is no further output from my program, Valgrind appears to be stuck in limbo waiting for the function call to complete, but it never does. Here is a minimal source that showcases the problem:

#include <SDL.h>
#include <iostream>

int main (int argc, char *argv[]) {
    std::cout << "SDL Init" << std::endl;
    if (SDL_Init(SDL_INIT_VIDEO) != 0 ) {
      std::cout << "SDL_Init Error: " << SDL_GetError() << std::endl;
      return 1;
    }
    std::cout << "Done" << std::endl;

    SDL_Quit();
    return 0;
}

Output when it hangs: (Edited to include extra debug info, generated using flags -v -d and --fair-sched=try)

SDL Init
--5591:1: aspacem allocated valgrind thread stack at 0x7000050db000 size 1064960
--5591:1:syswrap- run_a_thread_NORETURN(tid=2): pre-thread_wrapper
--5591:1:syswrap- thread_wrapper(tid=2): entry
--5591-- REDIR: 0x104be985a (libsystem_malloc.dylib:malloc_size) redirected to 0x10013fb50 (malloc_size)
--5591-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--5591:1:mallocfr newSuperblock at 0x700005262000 (pszB  294880) unsplittable owner VALGRIND/ttaux
--5591:1:mallocfr reclaimSuperblock at 0x7000050AB000 (pszB  196576) unsplittable owner VALGRIND/ttaux
--5591-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--5591-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
--5591:1: aspacem allocated valgrind thread stack at 0x70000532d000 size 1064960
--5591:1:syswrap- run_a_thread_NORETURN(tid=3): pre-thread_wrapper
--5591:1:syswrap- thread_wrapper(tid=3): entry
--5591:1: aspacem allocated valgrind thread stack at 0x700005431000 size 1064960
--5591:1:syswrap- run_a_thread_NORETURN(tid=4): pre-thread_wrapper
--5591:1:syswrap- thread_wrapper(tid=4): entry
--5591:1: aspacem allocated valgrind thread stack at 0x7000055b8000 size 1064960
--5591:1:syswrap- run_a_thread_NORETURN(tid=5): pre-thread_wrapper
--5591:1:syswrap- thread_wrapper(tid=5): entry
--5591-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times)
--5591:1:execonte resizing htab from size 1543 to 3079 (idx 2)  Total#ECs=1544
--5591-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 16 times)
--5591:1:hashtabl resizing table `MC_(malloc_list)' from 1543 to 3079 (total elems 1544)
--5591:1:syswrap- thread_wrapper(tid=3): done
--5591:1:syswrap- run_a_thread_NORETURN(tid=3): post-thread_wrapper
--5591:1:syswrap- run_a_thread_NORETURN(tid=3): not last one standing
--5591:1:syswrap- thread_wrapper(tid=5): done
--5591:1:syswrap- run_a_thread_NORETURN(tid=5): post-thread_wrapper
--5591:1:syswrap- run_a_thread_NORETURN(tid=5): not last one standing

Running just valgrind ./Application also gives errors (truncated):

Conditional jump or move depends on uninitialised value(s)
    at 0x7FFF5FC24A87: bcmp (in /usr/lib/dyld)....
Use of uninitialised value of size 8
    at 0x7FFF5FC24A9F: bcmp (in /usr/lib/dyld)....
Use of uninitialised value of size 8
    at 0x7FFF5FC24A9F: bcmp (in /usr/lib/dyld)....
Use of uninitialised value of size 8
    at 0x7FFF5FC24A9F: bcmp (in /usr/lib/dyld)....

EDIT: I've tried running it through gdb, its perfectly happy. Running it through helgrind or drd gives a segfault:11 in the SDL_Init call.

Helgrind: hg_main.c:4470 (void instrument_mem_access(IRSB *, IRExpr *, Int, Bool, Int, Int, IRExpr *)): Assertion 'szB > 8 && szB <= 512' failed.

Given that gdb is clean, I think something about running the SDL application through valgrind is causing this issue, but I've no idea what it could be, or how to work around this issue, and I cannot find any discussion about it to further my own investigations.

Full stacktrace from helgrind:

Thread 1: status = VgTs_Runnable (lwpid 2567)
==30388==    at 0x103BE5C3D: _dispatch_alloc_continuation_from_heap_slow (in /usr/lib/system/libdispatch.dylib)
==30388==    by 0x103BE5C0E: _dispatch_alloc_continuation_alloc (in /usr/lib/system/libdispatch.dylib)
==30388==    by 0x103BE59D6: dispatch_source_set_event_handler (in /usr/lib/system/libdispatch.dylib)
==30388==    by 0x103F16D05: _notify_lib_init (in /usr/lib/system/libsystem_notify.dylib)
==30388==    by 0x103F176C2: notify_register_dispatch (in /usr/lib/system/libsystem_notify.dylib)
==30388==    by 0x1021D0096: __71+[CFPrefsSource withSourceForIdentifier:user:byHost:container:perform:]_block_invoke_2 (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==30388==    by 0x103BE333E: _dispatch_client_callout (in /usr/lib/system/libdispatch.dylib)
==30388==    by 0x103BE3236: dispatch_once_f (in /usr/lib/system/libdispatch.dylib)
==30388==    by 0x1020C6A7A: +[CFPrefsSource withSourceForIdentifier:user:byHost:container:perform:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==30388==    by 0x10221D1AF: -[CFPrefsSearchListSource addSourceForIdentifier:user:byHost:container:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==30388==    by 0x10221C9E9: __73+[CFPrefsSearchListSource withSearchListForIdentifier:container:perform:]_block_invoke (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==30388==    by 0x10221C732: +[CFPrefsSearchListSource withSearchListForIdentifier:container:perform:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==30388==    by 0x10224F5C6: _CFPreferencesCopyAppValueWithContainer (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==30388==    by 0x10480B9C8: -[NSUserDefaults(NSUserDefaults) init] (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation)
==30388==    by 0x10480B3B6: +[NSUserDefaults(NSUserDefaults) standardUserDefaults] (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation)
==30388==    by 0x100BBE5C7: +[NSApplication initialize] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
==30388==    by 0x1003553C7: call_load_methods (in /usr/lib/libobjc.A.dylib)
==30388==    by 0x100355155: class_createInstance (in /usr/lib/libobjc.A.dylib)
==30388==    by 0x100354D07: NXMapRemove (in /usr/lib/libobjc.A.dylib)
==30388==    by 0x10034F590: objc_msgSend (in /usr/lib/libobjc.A.dylib)
==30388==    by 0x1000BDC8F: Cocoa_RegisterApp (in /usr/local/lib/libSDL2-2.0.0.dylib)
==30388==    by 0x1000C229B: Cocoa_CreateDevice (in /usr/local/lib/libSDL2-2.0.0.dylib)
==30388==    by 0x1000B655B: SDL_VideoInit_REAL (in /usr/local/lib/libSDL2-2.0.0.dylib)
==30388==    by 0x100020C69: SDL_InitSubSystem_REAL (in /usr/local/lib/libSDL2-2.0.0.dylib)
==30388==    by 0x100002E80: main (main.cpp:14)

This is compiled on an up to date El Capitan Macbook, Valgrind-3.12.0.SVN and LibVEX, and SDL2-2.0.4.

I've tried compiling both SDL2 and Valgrind fom the latest source (initially were obtained through brew) but that has had no impact.

Does anybody know how why Valgrind causes SDL_Init to segfault, and if there is a way to work around the issue?

Thanks

g0wen
  • 51
  • 3
  • Is it possible to link SDL2 statically instead? (i'm assuming you link it dynamically now bacause of the dyld printouts, i may be wrong...) – Martin G Feb 22 '16 at 06:31
  • Yes its linked dynamically currently, I will try linking it statically and report back. – g0wen Feb 22 '16 at 06:39
  • The problem isn't new at all: https://stackoverflow.com/search?q=UNKNOWN+mach_msg+unhandled+MACH_SEND_TRAILER+option Reconsider posting another questions instead of adding to one of the existing questions. – Ulrich Eckhardt Feb 22 '16 at 06:40
  • Not sure if you just skimmed my problem @UlrichEckhardt or I'm missing something... The results for that query return issues where Valgrind ran correctly, but gave false positives for SDL leaking memory. My issue is that Valgrind hangs on SDL_Init and *never completes* - it never gets past the SDL_Init call, no further output, nothing. – g0wen Feb 22 '16 at 07:04
  • No, you are right, I rather ignored the "hangs in SDL_Init()" part. I drew the faulty conclusion that the hanging must be related to the unknown MACH message. Sorry for the noise. – Ulrich Eckhardt Feb 22 '16 at 07:14
  • 1
    No worries, I think I could have made it clearer... hopefully it will be more obvious to somebody reading it now! Linking SDL2 statically doesn't change anything i'm afraid @Martin. – g0wen Feb 22 '16 at 07:48
  • 1
    Interestingly, running valgrind with --fair-sched=try it gets further than the first thread created, but still hangs (see above for output) – g0wen Feb 22 '16 at 13:34
  • When it hangs, you can use gdb and/or vgdb to examine the status of your program. See http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver for more info. – phd Feb 22 '16 at 22:46
  • @phd I have tried using vgdb, but there is no status to examine, gdb doesn't think theres anything wrong, it just sits and waits for valgrind to complete or error out, which it never does. – g0wen Feb 23 '16 at 22:49

0 Answers0