RESTOperation crashing in connection:didReceiveData:

[lenkawell]

Our users are getting regular crashes in RESTOperation that look like the enclosed stack trace. I don't quite see what the problem may be but it seems like it's crashing on the mutablecopy. Our users are running iOS 5.1 and I noticed that connection:didReceiveData: is deprecated as of iOS 4.3.

Incident Identifier: CA26A5B1-0ABB-4365-8959-14CF04DDDFDE
CrashReporter Key:   1a9f4934ec3ced1ecd18cd154b79a2e27482ec05
Hardware Model:      iPad2,1
Process:         Timebox [2429]
Path:            /var/mobile/Applications/8011C870-D1AE-4E9D-8B48-A199506F92E1/Timebox.app/Timebox
Identifier:      Timebox
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2012-08-15 10:40:45.227 -0700
OS Version:      iPhone OS 5.1.1 (9B206)
Report Version:  104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000010
Crashed Thread:  9


Thread 9 name:  Dispatch queue: com.apple.root.default-priority
Thread 9 Crashed:
0   Foundation                      0x37220542 -[NSConcreteMutableData initWithBytes:length:copy:freeWhenDone:bytesAreVM:] + 142
1   Foundation                      0x372369b6 -[NSData(NSData) initWithData:] + 98
2   Timebox                         0x000b9ac4 -[RESTOperation connection:didReceiveData:] (RESTOperation.m:430)
3   Foundation                      0x372b9c22 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke_0 + 10
4   Foundation                      0x372116d2 -[NSURLConnectionInternalConnection invokeForDelegate:] + 22
5   Foundation                      0x3721169c -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 192
6   Foundation                      0x372115be -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 54
7   Foundation                      0x3723a216 _NSURLConnectionDidReceiveData + 74
8   CFNetwork                       0x34bd9080 URLConnectionClient::_clientDidReceiveData(__CFArray const*, URLConnectionClient::ClientConnectionEventQueue*) + 260
9   CFNetwork                       0x34b3f4b0 URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload(XConnectionEventInfo<XClientEvent, XClientEventParams>*, long) + 436
10  CFNetwork                       0x34b3f592 URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload(XConnectionEventInfo<XClientEvent, XClientEventParams>*, long) + 662
11  CFNetwork                       0x34b3f592 URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload(XConnectionEventInfo<XClientEvent, XClientEventParams>*, long) + 662
12  CFNetwork                       0x34b3f19c URLConnectionClient::processEvents() + 100
13  CFNetwork                       0x34b3f0d2 MultiplexerSource::perform() + 150
14  CoreFoundation                  0x317a9acc __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 8
15  CoreFoundation                  0x317a9298 __CFRunLoopDoSources0 + 208
16  CoreFoundation                  0x317a803e __CFRunLoopRun + 646
17  CoreFoundation                  0x3172b49e CFRunLoopRunSpecific + 294
18  CoreFoundation                  0x3172b366 CFRunLoopRunInMode + 98
19  Foundation                      0x371f7b6e -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 250
20  Timebox                         0x000b88f0 -[RESTOperation wait] (RESTOperation.m:186)
21  Timebox                         0x000b179e -[CouchAttachment body] (CouchAttachment.m:105)
22  Timebox                         0x000e968c -[ThingDocument photoImageNamed:] (ThingDocument.m:173)
23  Timebox                         0x000d6e5e __36-[DetailViewController relayoutView]_block_invoke_0 (DetailViewController.m:447)
24  libdispatch.dylib               0x34978c52 _dispatch_call_block_and_release + 6
25  libdispatch.dylib               0x3497b810 _dispatch_worker_thread2 + 252
26  libsystem_c.dylib               0x33f9bdf4 _pthread_wqthread + 288
27  libsystem_c.dylib               0x33f9bcc8 start_wqthread + 0

[snej]

Our users are running iOS 5.1 and I noticed that connection:didReceiveData: is deprecated as of iOS 4.3.

No, the deprecation notice is just a weird side effect of breaking NSURLConnectionDelegate up into multiple protocols. The method still exists and is in the NSURLConnectionDataDelegate protocol.

[snej]

It looks as though the data parameter to -[RESTOperation connection:didReceiveData:] was corrupted somehow — it's not nil, but its data seems to be a bogus pointer (0x00000010?) No idea how this could happen, unless it's a result of TDURLProtocol sending a bad data object to the client?

Also I note that this request is getting the body of an attachment, so the data comes from the mapped contents of the attachment file…

[lenkawell]

Aha, I see, I was confused by the deprecation documentation.

Any ideas on what may be causing the crash? Is it something I may be doing wrong?

[snej]

Len, is this a regression? If so, what are the current and previous versions of TouchDB and CouchCocoa? There were some recent changes to the way attachment data is returned in TouchDB (568e267fe03b) but I don't see how it could cause this.

[snej]

And no, I don't think it's your fault. It really looks like TouchDB is returning a bogus data object, I just don't see how.

[lenkawell]

It might be a regression, since I can't find any of these crashes logged prior to moving to TouchDB 0.92 which I pulled and built on 8/8/12. The CouchCocoa was also pulled and built on 8/8/12. Since then, I have quite a few of these crashes.

[snej]

0.92 predates the router content-range changes I was thinking of, so that couldn't be it.
I've looked at the changes made since 0.92 and none of them seem to fix anything that could have caused bad data to be returned from the router...

[lenkawell]

Sorry, but I re-checked and the version that TouchDB reports is 0.93 (my mistake). I'm not sure when you bumped it to 0.93 from 0.92, but I definitely pulled and built it on 8/8/12, so anything changed prior to that is what I should have.

Git show says:

commit f6cf0b1c4cd2084c5496144a9feff88d96183dc4
Author: Jens Alfke [email protected]
Date: Wed Aug 8 14:37:54 2012 -0700