I don’t remember clearly, but I think you need to compile rack itself for asan. Anyone here remember?
1 Like
Yes, or at least re-link it.
1 Like
no, you don’t.
if you have plugins that are compiled with asan, and rack is not, you’ll see an error message about needing to preload asan libraries before executing rack. it will then give you a command to run that looks like this:
DYLD_INSERT_LIBRARIES=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib ./Rack -d
note that that’s the path on my machine for the asan libraries, so yours may be different. simply set the variable that it tells you to as you run rack.
no need to recompile or re-link.
1 Like
Good to know. But still recommend maybe? If you have problems like your plugin stomping on rack memory you will get a benefit from building both, won’t you?
1 Like
not really, no. you’ll still see your plugin stomping on rack memory. if you’re concerned about rack itself stomping on some other memory that’s unrelated to your plugin and are willing to take the performance hit, then by all means compile it with asan.
otherwise, when it comes to your own plugin, there’s no real benefit.
1 Like
Thanks @jerrysv. We must have very similar environments. I got asan working with the plugin using:
DYLD_INSERT_LIBRARIES=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib ./Rack -d -u ~/Documents/Rack -s /Applications/Rack.app/Contents/Resources
Unfortunately I have to go to work now… But it turns out I have a… Wild pointer? … potentially relating to port. I’ll check all of them after work. Might be my poly implementation.
==13716==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61800003e4c0 at pc 0x00000a17a5db bp 0x70000aaafe10 sp 0x70000aaafe08
WRITE of size 4 at 0x61800003e4c0 thread T13
#0 0xa17a5da in MusicalAnt::process(rack::engine::Module::ProcessArgs const&) Port.hpp:38
#1 0x1071569bd in rack::engine::Engine_stepModules(rack::engine::Engine*, int) (Rack:x86_64+0x1000c09bd)
#2 0x1071575aa in void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, rack::engine::Engine::start()::$_0> >(void*) (Rack:x86_64+0x1000c15aa)
#3 0x7fff6aacee64 in _pthread_start (libsystem_pthread.dylib:x86_64+0x5e64)
#4 0x7fff6aaca83a in thread_start (libsystem_pthread.dylib:x86_64+0x183a)
Address 0x61800003e4c0 is a wild pointer.
SUMMARY: AddressSanitizer: heap-buffer-overflow Port.hpp:38 in MusicalAnt::process(rack::engine::Module::ProcessArgs const&)
Shadow bytes around the buggy address:
0x1c3000007c40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1c3000007c50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1c3000007c60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1c3000007c70: 00 00 00 00 fa fa fa fa fa fa fa fa fa fa fa fa
0x1c3000007c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x1c3000007c90: fa fa fa fa fa fa fa fa[fa]fa fa fa fa fa fa fa
0x1c3000007ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c3000007cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c3000007cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c3000007cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c3000007ce0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
Thread T13 created by T0 here:
#0 0x10771278d in wrap_pthread_create (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5978d)
#1 0x107154581 in rack::engine::Engine::start() (Rack:x86_64+0x1000be581)
#2 0x1070fee61 in main (Rack:x86_64+0x100068e61)
#3 0x107098033 in start (Rack:x86_64+0x100002033)
==13716==ABORTING
Abort trap: 6
before you dive too far into that, did you try the configParam fix that I suggested, and also the draw fix that @Coirt suggested?
try those before you get too deep.
I suggested both 
mine was that the number of parameters being instantiated was way more than the number of parameters being configured 
I thought yours was a namespace change?
yeah, that doesn’t matter, since a namespaced enum is the same value as a non-namespaced enum.
Does not need to be called again as it is in scope of the enumerator. Can’t remember when this was changed, some time pre-release v1 possibly, but it used to give an error does not now.
Hi guys, yeah, sorry, I did makes some updates based on your feedback. Possibly not exhaustively though.
Which repo branch are you working off here?
I prefer to explicitly namespace everything myself. Old habits, I guess.
NewPath: 641ea9461896885ec8bf18579b762105c389154b
I should have specified. That said, I’ve mostly been bug-hunting and pruning old crap since the branch rather than making real changes.
It’s a Christmas Miracle!! I’m 99% sure I’ve located and fixed the issue!
It turns out when I updated for poly output I managed to define the voltage output as a param rather than an output.
Thank you very much all who helped me sort this out. Happy holidays all!! 
I hope Santa brings you all sorts of synthy goodness.
Cheers, Alex
2 Likes
One reason I prefer the newer “enum class” syntax.
2 Likes