Tips for tracking down inconsistent memory errors?

[Fender19]

I am working on a plugin that runs perfectly in VST, VST3 and AAX formats - sometimes runs in Reaper in AU format - but always FAILS in Logic. Repeatedly running auval shows inconsistent pass/fail results indicating erratic "malloc" errors.

Why are the reported memory errors only crashing the AU version? IDK

Auval will run several times in a row with "AU VALIDATION SUCCEEDED" but then on the next attempt fails. Example (failed) auval results:

• /usr/bin/auval: line 8: 859 Segmentation fault: 11 arch -x86_64 /usr/bin/auvaltool "$@"

• auvaltool(875,0x10fdf85c0) malloc: Incorrect checksum for freed object 0x7fd2db815410: probably modified after being freed.
  Corrupt value: 0x7fd200000000

On the very next run of auval it reported "AU VALIDATION SUCCEEDED"!

Any tips on how to track this down? I have attempted to troubleshoot using symbolic breakpoint "malloc_error_break" but the information it returns isn't much help. How do I find out what LINE(s) OF CODE is producing these errors?

[cpr]

I still haven't used it, but is this a job for ASAN?

[syntonica]

Instruments can help you track down leaks, zombies and CPU hogs. It really is useful and is your friend.

If you keep your debug info, don't optimize, and you can get your plugin to crash, the error report will tell you which line is the culprit. I haven't fought with auval in quite a while, so it may be suppressing error reports. Look to the Console to see if they are there.

[quikquak]

Can XCode have breakpoints on memory writes, like on Visual Studio?
I suspect you're still using something in the DSP code from the editor when the DSP frees itself?

[Fender19]

Can XCode have breakpoints on memory writes, like on Visual Studio?
I suspect you're still using something in the DSP code from the editor when the DSP frees itself?

IDK but I have been on a "wild goose chase" with it. Xcode says the problem is "HERE" so I make some changes then it says the problem is "OVER THERE" - make some changes. Still doesn't work.

Now I discovered a new problem in that some of my older Released plugins that worked perfectly do not validate or run when re-compiled NOW. So something in my compiler settings, OS, permissions or library files has changed. Time to "drop back and punt" and restore backups...

[quikquak]

So it looks like you can use memory write breaks? They are one of the best way of finding a memory stomper, because no code changes, and it catches multi-threaded writes. Stop the code with a break point in 'process' or 'prepare' first (if it gets there), then set the memory break-point to catch a crash.

Removing large chunks of code forces you to study your code a little closer, so 'drop back and punt' is always going to be fun!


*edit* Just found this: https://www.donnywals.com/using-xcodes- ... ory-leaks/

[Fender19]

So it looks like you can use memory write breaks? They are one of the best way of finding a memory stomper, because no code changes, and it catches multi-threaded writes. Stop the code with a break point in 'process' or 'prepare' first (if it gets there), then set the memory break-point to catch a crash.

Removing large chunks of code forces you to study your code a little closer, so 'drop back and punt' is always going to be fun!


*edit* Just found this: https://www.donnywals.com/using-xcodes- ... ory-leaks/

Will check this out. Thank you!

[superplek]

I could also recommend running it through Valgrind if you can make that work for your project. Otherwise there are CRT debug functions to trap leaks and such; from the looks of it it's very likely that you're trashing some memory. These bugs can go unnoticed depending on the environment your software runs in.