Detected memory leaks after update to v8

General JUCE discussion
1 
    JUCE v8.0.0
    Detected memory leaks!
    Dumping objects ->
    {3138} normal block at 0x0000022AE186FAD0, 6 bytes long.
     Data: <es-es > 65 73 2D 65 73 00 
    {3137} normal block at 0x0000022AE186FFD0, 16 bytes long.
     Data: <@ r *       *   > 40 B0 72 E1 2A 02 00 00 D0 FA 86 E1 2A 02 00 00 
    {2935} normal block at 0x0000022AE16BC610, 2 bytes long.
     Data: <c > 63 00 
    {2934} normal block at 0x0000022AE172B040, 16 bytes long.
     Data: <          k *   > 00 00 00 00 00 00 00 00 10 C6 6B E1 2A 02 00 00 
    {2931} normal block at 0x0000022AE1713F00, 216 bytes long.
     Data: <                > 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    {2911} normal block at 0x0000022AE09CFC00, 184 bytes long.
     Data: <                > 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    Object dump complete.

I have removed all my code and the message still appears when I close the application

JUCE 8 - Memory Leak
2

+1

We’re also seeing memory leak warnings after updating to JUCE 8 in pretty much all our projects. This doesn’t happen with the latest JUCE 7 master branch.

3

Assuming this is on Windows this must be the same as JUCE 8 - Memory Leak

4

I have been facing the same issue since the beta, but the JUCE team was not able to reproduce it.
I don’t know if this is related but I also get “MONZA” exceptions.

I have a feeling this is related to the GPU I use (an intel 14th gen iGPU).

5

Because of this issue and this PR not being merged this is kind of annoying to troubleshoot.

I was able to set _CrtSetBreakAlloc on the allocation order numbers and it seems to be related to font stuff:

2701.txt (3.2 KB)
2721.txt (3.2 KB)
2724.txt (3.4 KB)
2725.txt (3.8 KB)
2942.txt (3.8 KB)
2943.txt (4.0 KB)

I tried setting _ITERATOR_DEBUG_LEVEL to 0 to see if it was an allocation problem with Debug, but it didn’t make a difference.

6

the memory leak warnings also appear for macOS.

7

Thanks for reporting. The issue should be resolved by this commit on the develop branch:

Please try updating to the develop branch and see whether the issue is fixed for you.

The original issue reported in this thread is MSVC leak checker output, so this warning won’t appear on macOS. I expect that the macOS warnings are different. Please could you provide the text of the warning you’re seeing, along with the steps you’re taking to produce the warning, including the problematic plugin format and host (if any).

8

After the update it has been solved

9

Thanks @reuk for the fix for MSVC; I don’t see any memory leak warnings on Mac anymore either (may have been the result of other changes that we’ve made in the meantime).

10

I had the same issue on my Windows 11 machine after downloading JUCE 8. To see whether there might have been any hidden leaks in my code that went unnoticed in version 7, I had https://www.deleaker.com/ have a look at it. It found quite many leaky code passages, actually, but all in JUCE 8 code, not in mine. Out of curiousity, I then also ran it on JUCE 7 code and it also reported memory leaks – not as many as in version 8, although nothing was mentioned in the console output. Maybe you should run such a tool yourself…

11

Is this fix in the latest Juce 8.0.1 release? I updated to it and there’s still the memory leak when closing. I notice that whenever I resize the window the memory usage spikes ~100mb. I simply reverted to Juce 7 for now

12

Can confirm this still happens in JUCE v 8.0.8 when using juce::DatagramSocket to send/receive data. Any updates?

13

A fix for the original issue was already posted above. If you’re still seeing leak reports, I suspect that these are new leaks with a different underlying cause.

Do you see the same problem in any of the JUCE demos? The OSCDemo uses DatagramSockets internally, and I don’t see any leaks in that program.

Please can you provide either:

  • a minimal program that demonstrates the leaks, or
  • instructions to trigger the leaks in one of the JUCE demo programs?

Another technique you could try to narrow down the cause of the problem is to use git bisect to locate the JUCE commit that introduced the leaks. This assumes that the leak you’re seeing is a new issue, and that your program does not leak when built against an older version of JUCE. If we know which change introduced the problem, then we may be able to find the cause by inspecting the diff.