WebInputStream memory leak?

General JUCE discussion
1

I’m doing this once every three seconds:

{
    int param = 1;
    String user("foo:bar");
    String user64 = Base64::toBase64(user.getCharPointer(), user.length());
    String header = "Authorization:Basic " + user64;
    URL url("https://www.foo.com/somescript.php");
    std::shared_ptr<InputStream> stream(url.withParameter("param", String(param)).createInputStream(true, nullptr, nullptr, header, 3000));
}

It seems to cause a memory leak. I tried another version of it using WebInputStream that does not need to use a std::shared_ptr, but it has the same result (and the code above uses WebInputStream under the hood). I poked around a bit in xcode->profiler->instruments->leaks and it seemed to point to the connect call in WebInputStream. I’m on macOS 10.13.6, xcode 10.1, JUCE 5.4.3. I normally have code that parses the input stream, but I removed it to eliminate it as a source of the leak.

2

Try std::unique_ptr instead of the shared :slight_smile:

3

Yes - given only this code snippet, that would be a more appropriate thing to use. But it doesn’t change the leak problem. For the record, this also seems to leak:

{
    int param = 1;
    String user("foo:bar");
    String user64 = Base64::toBase64(user.getCharPointer(), user.length());
    String header = "Authorization:Basic " + user64;
    URL url("https://www.foo.com/somescript.php");
    WebInputStream stream(url.withParameter("param", String(param)), true);
    stream.withExtraHeaders(header).withConnectionTimeout(3000).connect(nullptr);
}
4

Right, shared_ptr should do the same job. However, the code above works without leaks when I try it. So the leak is gone when you remove that code?

5

Make sure, the object that owns the code you posted, has the JUCE_LEAK_DETECTOR or JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR defined. If the containing object is leaked, but isn’t known to the leak detector, you will only see the owned class leaking.

Also, when you experience a leak, click continue a few times, so you will find the possibly leaked objects, that contain the other ones (hope that’s not phrased too confusing).

6

The containing class that owns the code above is protected with JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR. Juce never gives a leak detection. I came to my conclusion by looking at the memory consumption graph over time in xcode and then investigating that with profile->instruments->leak. This thread inspired me to simplify the above code to further isolate the WebInputStream class. So, I created a new GUI application in Projucer. I just inherited Timer in the MainComponent class and added this:

void MainComponent::timerCallback()
{
    URL url("https://www.google.com");
    WebInputStream stream(url, true);
    stream.connect(nullptr);
}

The memory usage increases over time in the “Debug Navigator” in xcode. It has a period of ~10 to 15 seconds where it increases noticeably, then it continues to increase at a much lower rate so you have to give it a while to see it. This can be compared to no memory usage increase when commenting out the above three lines of code.

The code will trigger these annoying messages from some OS X networking code (common complaint on the internet):
2019-07-20 11:22:09.323774-0600 NewProject[12614:338094] TIC Read Status [6:0x0]: 1:57
2019-07-20 11:22:09.323806-0600 NewProject[12614:338094] TIC Read Status [6:0x0]: 1:57
2019-07-20 11:22:10.323592-0600 NewProject[12614:338094] TIC Read Status [7:0x0]: 1:57
2019-07-20 11:22:10.323625-0600 NewProject[12614:338094] TIC Read Status [7:0x0]: 1:57

So, I feel like I am stretching to justify the memory increase as due to this logging? Doesn’t seem like enough bytes that it would even register on the memory usage graph. The Release build also has this logging, so there is no easy way to turn it off.

7

Unfortunately there’s not even a difficult way to turn it off:

https://forums.developer.apple.com/message/272678#272678

1 Like
8

Are JUCE LEAK DETECTOR macros fully sufficient to track down issues? I ask because I was directed to the below tool for more detailed tracking.

For details on leaks, I was directed towards jcf_advanced_leak_detector.h found at, jcredland’s juce-toys

However, some guidance would be appreciated. I had it working once, then suddenly on rebuilding a project I had some strange errors.

Has anyone used this diagnostic code for ensuring a robust JUCE App? Or are there others?
Thanks in Advance.