ARC iOS build, TCP, crash in Dispatch queue: GCDAsyncSocket

[whitehexagon]

It's a bit of a weird one, I've spent a lot of time trying to track
this one down. Since I migrated my whole project to ARC including the
networking layer ie. GCDAsyncSocket, I've suddenly started getting
random crashes in my app when streaming network data.

XCode 4.2 under Snow Leopard, testing on iPad 2 iOS 5.0.1, but also
simulator and iPhone 4.

In XCode all I get is the debugger states 'Paused' and there is no
strack trace, console output and continue does nothing. Have -Wall
and Scheme diagnostics on.

I finally came up with the idea of looking for stack traces on the
device, and I came across plenty of instances of this:

Thread 7 name: Dispatch queue: GCDAsyncSocket
Thread 7 Crashed:
0 libobjc.A.dylib 0x3790bfbc 0x37908000 + 16316
1 MyApp1234 0x00074fd2 0x1000 + 475090
2 MyApp1234 0x0007436c 0x1000 + 471916
3 MyApp1234 0x000712a8 0x1000 + 459432
4 libdispatch.dylib 0x3098333e 0x3097e000 + 21310
5 libdispatch.dylib 0x30980c60 0x3097e000 + 11360
6 libdispatch.dylib 0x30980d9e 0x3097e000 + 11678
7 libdispatch.dylib 0x30980c56 0x3097e000 + 11350
8 libdispatch.dylib 0x30981860 0x3097e000 + 14432
9 libsystem_c.dylib 0x378841c8 0x3787a000 + 41416
10 libsystem_c.dylib 0x3788409c 0x3787a000 + 41116

running the app though 'leaks' shows nothing.

It used to be with the pre ARC GCDAsyncSocket that the app would run
for hours, no its down to minutes on the devices and a bit longer in
the simulator (20--40mins).

I've tried with GCDAsyncSocket debug enabled and sometimes that seems
to extend the time before a crash, but doesn't give any hints in the
console of unusual activity.

At this point I'm wondering what else I can try, I don't really want
to rollback pre ARC.

Any tips for debugging this further?

Cheers
Peter

PS
Very Occasionally the debugger will stop/crash at:
if (delegateQueue && [delegate
respondsToSelector:@selector(socket:didReadData:withTag:)])
but I suspect this is a different issue caused by a low memory
condition.

[Robbie Hanson]

Are you remembering to call [socket setDelegate:nil] in your dealloc method?

-Robbie Hanson
Sent from my iPhone

> --
> You received this message because you are subscribed to the Google Groups "CocoaAsyncSocket" group.
> To post to this group, send email to cocoaasy...@googlegroups.com.
> To unsubscribe from this group, send email to cocoaasyncsock...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cocoaasyncsocket?hl=en.
>

[whitehexagon]

The delegate lives the whole time, so there shouldnt be any allocation/
deallocation going on. I'm continually streaming over a single socket
when it crashes. I'm gonna try this week to put together a test
that demonstrates the issue.

[whitehexagon]

I've taken out my own threading layer now that GCDAsyncSocket has it's
own nice queues, in fact I've rewritten most of my network layer now,
to better work with the new API and suddenly things are much more
stable. It could possibly have been related to the low memory
condition, but since XCode was not showing any information it's
impossible to know for sure. Basically I was streaming large amounts
of data via a buffer, any delays on the networking was causing the
buffer to back up, which in turn was causing low memory conditions.
I'm still trying to work out how best to deal with that, since it can
happen quite frequently that my apps see WiFi dropouts, and the
synchronizations points in the streamed data are not easy to locate
(assuming I try to empty out the buffer prematurely). Anyway, I'm
feeling much happier with the whole ARC experience, and once again I
thank you for a great library, and for keeping it updated!

[Venelin Gornishki]

I've run into a similar problem. Can you please explain how you actually solved it in your case.

Thanks.