[Solved] Anyone else? Rampant memory use in El Capitan and higher

Discovered an odd problem and wondering if it sounds familiar to anyone else… Legacy plugin built from a JUCE fork in the 4.0.1 era - runs fine on any OS 10.10 and below. Starting with OS 10.11 El Capitan, opening/closing the plugin UI (ie. clicking on the insert in Pro Tools) results in dramatic memory increases displayed in Activity Monitor - around 100Mb per open/close cycle which is probably close to the whole memory footprint of the plug. It’s not constant, though - it increases in size a bit with each cycle. Memory use is stable while the plug-in is either open or closed. Memory use is stable under previous OSes.

“Does it happen on the tip?” - This is a legacy plug and the massive changes from 4.0.1 to current tip make it impractical to migrate to the latest. Hoping this sounds familiar to someone and a fix can be cherry-picked. The El Cap headaches I see in the repo seem to be more focused on rect coalescing and repaint message queueing, which seems unlikely to be related.

Anyone else recall seeing anything like this?


Edited: OS versions were off by .1 in OP. Problems start in 10.11 El Cap, also confirmed in 10.12 Sierra.

macOS 10.11 is OS X El Capitan (https://en.wikipedia.org/wiki/OS_X_El_Capitan). So which version is problematic exactly?

Argh, post fixed. Problems indeed start in 10.11 El Capitan, 10.8, 10.9, 10.10 are all fine using the same exact installer of the plug-in and DAW.

how about just bumping it up to 4.3.1 then?

Migrating to 4.3.1 would require substantial intrusive changes to the code and to the build processes we have in place, as well as exhaustive testing to ensure nothing broke in the transition. Among the major changes: mutlibus, changes to parameter IDs and parameter handling in general, the fundamental changes to project organization introduced in 4.2, and the VST 3.6.7 SDK requirement after commit 9C7ee87. We also have extensive customizations to the JUCE plug-in classes that would likely require substantial refactoring given the changes to those classes in the main JUCE repo since 4.0.1. Nothing impossible, but definitely a high risk of introducing subtle problems or corner cases in backwards compatibility with one of the 12 variants running on half a dozen different OSes and dozens of different DAWs. And not something we could do in half a day just to see if this issue goes away.

Was eventually able to identify use of a custom font as the trigger, and unearthed the following fix to modules/juce_graphics/native/juce_mac_Fonts.mm line 548, buried in the BLOCKS updates in commit 76b3689:

-         CFDataRef cfData = CFDataCreate (kCFAllocatorDefault, (const UInt8*) data, (CFIndex) dataSize);
+         CFDataRef cfData = CFDataCreateWithBytesNoCopy (kCFAllocatorDefault, (const UInt8*) data, (CFIndex) dataSize, kCFAllocatorNull);

To clarify: the issue is fixed in the current tip, this is only an issue for people working off an older fork.

Posting this here for posterity in the hopes it will save someone else a lot of headaches.