Occasional Crash in juce_mac_network.mm

General JUCE discussion
1

Hello, sometimes when generating many WebInputStreams on mac, I haven’t tested PC, I get a SIGSEGV at this line in the URLConnectionState class:

void didReceiveResponse (NSURLResponse* response, id completionHandler)
{
    {
        const ScopedLock sl (dataLock);
        [data setLength: 0];
    }
...
}

this occurs on the line [data setLength: 0] which is being called after:

private:
    static void didReceiveResponse (id self, SEL, NSURLSession*, NSURLSessionDataTask*, NSURLResponse* response, id completionHandler)
    {
        getState (self)->didReceiveResponse (response, completionHandler);
    }

Here is the stack trace if anyone can make any sense of this:

#0	0x00007fff85737446 in cache_getImp ()
#1	0x00007fff8573cc87 in lookUpImpOrForward ()
#2	0x00007fff8573ed8f in lookUpImpOrNil ()
#3	0x00007fff85740fba in class_respondsToSelector ()
#4	0x00007fff98fd0533 in ___forwarding___ ()
#5	0x00007fff98fd00f8 in __forwarding_prep_0___ ()
#6	0x0000000117c801ce in juce::URLConnectionState::didReceiveResponse(NSURLResponse*, objc_object*) at /Users/mumu/Development/Plugins/Mumu/MumuPlugin/Builds/MacOSX/../../../../../juce-grapefruit-osx/modules/juce_core/native/juce_mac_Network.mm:202
#7	0x0000000117c7fd09 in juce::URLConnectionState::DelegateClass::didReceiveResponse(objc_object*, objc_selector*, NSURLSession*, NSURLSessionDataTask*, NSURLResponse*, objc_object*) at /Users/mumu/Development/Plugins/Mumu/MumuPlugin/Builds/MacOSX/../../../../../juce-grapefruit-osx/modules/juce_core/native/juce_mac_Network.mm:321
#8	0x00007fff99d708d7 in __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ ()
#9	0x00007fff99d70595 in -[NSBlockOperation main] ()
#10	0x00007fff99d6ec7a in -[__NSOperationInternal _start:] ()
#11	0x00007fff99d6ac64 in __NSOQSchedule_f ()
#12	0x000000010484dcc5 in _dispatch_client_callout ()
#13	0x0000000104853112 in _dispatch_queue_drain ()
#14	0x000000010485ae24 in _dispatch_queue_invoke ()
#15	0x0000000104851dab in _dispatch_root_queue_drain ()
#16	0x00000001048518a5 in _dispatch_worker_thread3 ()
#17	0x00000001048b0336 in _pthread_wqthread ()
#18	0x00000001048adf91 in start_wqthread ()

Not sure exactly what is happening, but i don’t believe that I’m doing anything funky with the URL->createInputStream() as it is pretty straight forward.

Thanks!

2

Also have seen it here inside the same URLConnectionState:

void didReceiveData (NSData* newData)
{
    const ScopedLock sl (dataLock);
    [data appendData: newData];
    initialised = true;
}

after:

static void didReceiveData (id self, SEL, NSURLSession*, NSURLSessionDataTask*, NSData* newData)
{
    getState (self)->didReceiveData (newData);
}

Stack Trace:

#0	0x00007fff857374dd in objc_msgSend ()
#1	0x0000000117462478 in juce::URLConnectionState::didReceiveData(NSData*) at /Users/mumu/Development/Plugins/Mumu/MumuPlugin/Builds/MacOSX/../../../../../juce-grapefruit-osx/modules/juce_core/native/juce_mac_Network.mm:239
#2	0x0000000117461e81 in juce::URLConnectionState::DelegateClass::didReceiveData(objc_object*, objc_selector*, NSURLSession*, NSURLSessionDataTask*, NSData*) at /Users/mumu/Development/Plugins/Mumu/MumuPlugin/Builds/MacOSX/../../../../../juce-grapefruit-osx/modules/juce_core/native/juce_mac_Network.mm:331
#3	0x00007fff9a7ab1e1 in __67-[NSURLSession delegate_dataTask:didReceiveData:completionHandler:]_block_invoke226 ()
#4	0x00007fff99d708d7 in __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ ()
#5	0x00007fff99d70595 in -[NSBlockOperation main] ()
#6	0x00007fff99d6ec7a in -[__NSOperationInternal _start:] ()
#7	0x00007fff99d6ac64 in __NSOQSchedule_f ()
#8	0x000000010484dcc5 in _dispatch_client_callout ()
#9	0x0000000104853112 in _dispatch_queue_drain ()
#10	0x000000010485ae24 in _dispatch_queue_invoke ()
#11	0x0000000104851dab in _dispatch_root_queue_drain ()
#12	0x00000001048518a5 in _dispatch_worker_thread3 ()
#13	0x00000001048b0336 in _pthread_wqthread ()
#14	0x00000001048adf91 in start_wqthread ()
3

Can you try the fix that I have just pushed to the develop branch? Can you still reproduce the issue?

4

Thanks Fabian,

It’s quite sporadic so I’m not 100% positive, but I just tried to make it happen about 200 times and it didn’t occur (It definitely would have before). Seems that small change has made everything behave more robustly, there are also much less failed connections occurring.

Excellent! I’ll keep an eye out for when you merge this back into master. Is there a reason that you’re referring to the implementation as legacy?