User's patch that crashes on Mac, and only while using my modules.

Development
1

Hey all, I have a user I’ve been working with who is experiencing VCV Rack crashes, and only when my Memory modules are used. But I can’t reproduce it on my Windows machine, and the stack trace their log.txt doesn’t point to my modules at all.

Here’s the patch: Crashes on Mac.vcv (9.3 KB)

Here’s a stack trace from them:

[546.954 fatal adapters/standalone.cpp:49 fatalSignalHandler] Fatal signal 11. Stack trace:
/Applications/VCV Rack 2 Free 2.6.4.app/Contents/MacOS/Rack: fatalSignalHandler(int) +0x28
/usr/lib/system/libsystem_platform.dylib: _sigtramp +0x38
/usr/lib/system/libsystem_malloc.dylib: tiny_free_no_lock +0x1a0
/usr/lib/system/libsystem_malloc.dylib: tiny_free_no_lock +0x1a0
/usr/lib/system/libsystem_malloc.dylib: free_tiny +0x1cc
/System/Library/Frameworks/Metal.framework/Versions/A/Metal: -[_MTLObjectWithLabel dealloc] +0x40
/System/Library/Frameworks/Metal.framework/Versions/A/Metal: -[_MTLCommandBuffer dealloc] +0x24c
/System/Library/PrivateFrameworks/IOGPU.framework/Versions/A/IOGPU: -[IOGPUMetalCommandBuffer dealloc] +0xd4
/System/Library/Extensions/AGXMetal13_3.bundle/Contents/MacOS/AGXMetal13_3: -[AGXG13GFamilyCommandBuffer dealloc] +0x294
/usr/lib/system/libsystem_blocks.dylib: _call_dispose_helpers_excp +0x30
/usr/lib/system/libsystem_blocks.dylib: _Block_release +0xec
/System/Library/PrivateFrameworks/IOGPU.framework/Versions/A/IOGPU: IOGPUNotificationQueueDispatchAvailableCompletionNotifications +0x90
/System/Library/PrivateFrameworks/IOGPU.framework/Versions/A/IOGPU: __IOGPUNotificationQueueSetDispatchQueue_block_invoke +0x40
/usr/lib/system/libdispatch.dylib: _dispatch_client_callout4 +0x10
/usr/lib/system/libdispatch.dylib: _dispatch_mach_msg_invoke +0x1d0
/usr/lib/system/libdispatch.dylib: _dispatch_lane_serial_drain +0x14c
/usr/lib/system/libdispatch.dylib: _dispatch_mach_invoke +0x1d8
/usr/lib/system/libdispatch.dylib: _dispatch_lane_serial_drain +0x14c
/usr/lib/system/libdispatch.dylib: _dispatch_lane_invoke +0x1b8
/usr/lib/system/libdispatch.dylib: _dispatch_lane_serial_drain +0x14c
/usr/lib/system/libdispatch.dylib: _dispatch_lane_invoke +0x184
/usr/lib/system/libdispatch.dylib: _dispatch_root_queue_drain_deferred_wlh +0x124
/usr/lib/system/libdispatch.dylib: _dispatch_workloop_worker_thread +0x21c
/usr/lib/system/libsystem_pthread.dylib: _pthread_wqthread +0x124
/usr/lib/system/libsystem_pthread.dylib: start_wqthread +0x8

User says it often takes several minutes of running for the crash to occur; it looks like the crash above happened right around the ten minute mark. They also say that “However, removing ST sampler modules [i.e., the Stochastic Telegraph Memory modules] and putting in another sampler module makes it play without crashes for 1+ hr (so far).”

I can speculate on what’s going on (e.g., there’s something in the ST modules tickling a graphics bug in VCV Rack?), but I can’t prove it. User was experiencing this on both Rack 2.5.2 and 2.6.4.

Is there anyone with a Mac dev environment that could help pin down what’s going on?

2

This smells like a memory corruption issue. The cause could be anywhere, and the stack trace is just pointing to an innocent victim.

For this kind of issue it would be helpful to run the repro scenario under valgrind.

2 Likes
3

yes, exactly. I’ve been through this, thought it was my module, ran it under address sanitizer, valgrind… it wasn’t me. Turned out to be “some other module”. memory corruption manifests in all kinds of crazy ways. It’s kind of amazing that VCV works at all…

1 Like
4

I’ve been running the fairly stock Windows development chain as described here, and I don’t see a path to making Valgrind or ASan work in that environment. Do you know if I’m mistaken about that?

If I’m not wrong about that, what path should I follow to get to a place where I can use these tools (which do seem like a good idea to have access to)? I suspect there’s a lot of paths to getting there, but not sure which is likely to be the least aggravating.

Thoughts?

5

The least aggravating path I know if you want to run Valgrind in Windows… is using a VMWare virtual machine (I believe it can work under WSL; but it makes an already slow process even slower, from what I hear).

Depending on your taste and preference for or aversion to GUIs (and dealing with some of the developer’s odd choices and, at times, weird GUI), you could set up Eclipse’s Valgrind support: it produces nice output and clickable lines; again under a real or virtual Linux, though.

Another tool I’ve found really useful for dealing with certain issues, is CPP check… there’s a native Windows version of that with and without a GUI.

6

Yeah, I use Linux in a vm for that. My unit test run under visual studio, and that has built in Asan support, so that’s kind of handy.

7

I have run Rack under valgrind in WSL before, but it crawls. Only used it for a very simple scenario with just one module. Much less painful on a linux box. I have an old Surface Pro3 running Linux Mint I use for Linux stuff.

There’s a VSCode extension for cppcheck that you can use on Windows. It’s a different beast than valgrind, but can uncover similar issues.

8

I have found that at least in ubuntu / vmware that valgrind was still insanely slow. But address sanitizer wasn’t.

Is cpp check still a thing? As you can see, my VS has address sanitizer ™ installed. different names for the same thing?

image
image482×530 26.1 KB

9

oh, I see. cppcheck is a static analysis tool.