I’ve seen a very similar memory leak whilst using Projucer 5.0.0 (build downloaded directly from juce.com) under Sierra 10.12.4 (16E195).
This is basically exactly the same thing as mine. Exact same outcome. Hope they address this soonish.
Also, I’m on the same OS: macOS 10.12.4
Same here, among other craziness, on Windows 10.
That’s concerning - I’m looking into it but I can’t seem to reproduce it. I’ve had the Projucer running for an hour or so and Activity Montior doesn’t show any abnormal memory usage and Xcode’s leak checker seems happy too. Are you doing anything in particular in the Projucer when this happens?
It’s only happened to me once so far, but by the time I noticed it, my system was unresponsive, so I didn’t get a chance to investigate Projucer’s state.
From memory, I think I had enabled the compilation engine (not live compiling) and it may have encountered errors (perhaps the “precompiled headers don’t match …” message, but I’m really not sure about this); it’s also likely that I had a second .jucer project open. The .jucer projects and Projucer.app now I come to think of it, were in my Dropbox and the Dropbox client was running; I can see Dropbox was running on @joe_04_04’s machine too. I also happened to be on a train out of WiFi at the time my system became un-responsive, although I had been on WiFi not too long before. I left Projucer open whilst working in Xcode for about an hour and boom.
I’ll keep activity manager open and if it happens again, try to catch it sooner. Any useful steps I can take (beyond, “what did I do”) to provide decent debugging info if / when this happens?
I have also had same issue: macOS 10.12.4
A fix for this will appear shortly.
OK this should now be fixed in the 5.0.1 release, however because it’s so tricky to reproduce it’s hard to know for sure. If you run into it again please let me know.
I noticed it in 5.0.0 as I occasionally ran out of memory. I’m just testing 5.0.1 and my activity monitor shows that every time the live build does a build, it takes a bit more memory. I doubt that this is supposed to happen?
Further testing shows it jumps up 10MB each time it builds. To test I was adding and removing “int one;” from the audio processor header.
Ahh, yep I’m seeing this now too. Back to the drawing board…
OK, I think this should be fixed now. Can you grab the latest version of the compile engine and let me know how you get on? If you’re on mac, you need to remove JUCECompileEngine.dylib from Projucer/Contents and also user/Library/Application Support/Projucer and if you’re on Windows you need to remove the .dll from next to the Projucer.exe file (if it’s there) and \Users\username\AppData\Roaming\Projucer-version number. Then when you re-open the Projucer it should prompt you to download the newest compile engine.
@ed95 Thanks for the detailed description on how to make the Projucer download the latest compile engine.
I’m new to using the live compile engine. On OSX it looks like you create a separate folder for each release of the Projucer, e.g. ~/Library/Application Support/Projucer-5.0.0/, ~/Library/Application Support/Projucer-5.0.1/. This will add a lot of Projucer-x.y.z folders over time. All other applications I have only create one folder to ‘Application Support’. Why not use the scheme ~/Library/Application Support/Projucer/5.0.1/ instead?
Your post indicates that if a new JUCECompileEngine.dylib gets created without a version number increase of JUCE/Projucer, user interaction is needed to not end with a Projucer - compile engine mismatch. Why not add a time-stamp-versionnumber to the compile engine? The Projucer could then compare the local version and the ROLI version and download if needed.
In general, could you make this and similar usage information easier to find? For example in a readme file in the Projucer project folder.
Yeah the versioning methods could certainly be improved - I’ll add this to the backlog of Projucer-related fixes and tweaks that I’ve got going.
So far I haven’t had any problems with it now and have been using it a couple of hours so it looks good to me.
I removed the two files you mentioned on Mac, but was never prompted a download for a new compile engine. My continuous build and build now buttons are blanked out.
If you navigate to the live-build tab in the Projucer do you see a button that prompts you to download the new version?
Ahhh yes… Found the link for the manual download. Silly me…
I downloaded the new engine, but am getting a segmentation error. Is this an indication of an error on my end? I’m not familiar at all with the JIT engine, but I don’t have any segmentation errors when running my apps in other coding environments. This was the issue I had all during my use of JUCE 4.
Do you get these errors when running a JUCE example project such as the Demo?