EXC_BAD_ACCESS after a addAttachment

4001
1
Jump to solution
05-28-2013 04:17 PM
ChristopheFondacci
New Contributor II
Hi !

Sorry but it's been a week I am struggling with this problem and I cannot find any valid solution / workaround.

Here it is:

  • I have a valid feature layer (as an instance "retain" variable)

  • The feature layer has editing capabilities and attachments are enabled

  • I add attachments to an existing object by calling addAttachment method of my feature layer

  • The operation starts, ends, my callback "didAttachmentEditsWithResults" is called, everything is in success. I do nothing in my callback except logging the event.

  • Almost immediately after my callback is called with SUCCESS, the app throws EXC_BAD_ACCESS

  • After the crash when I restart the app, I can see that everything has been done : attachments are here and are correct.

Here is my code :
                // Processing all images as attachments                 for(MobileImage *mobileImage in mappedInfo.images) {                     // Getting NSData from PNG representation of image                     NSData *data = UIImagePNGRepresentation(mobileImage.image);                                          // Starting attachment operation                     [self startOp:@"Envoi des photos"];                     [_featureLayer addAttachment:objectId data:data filename:[NSString stringWithFormat:@"photo%d.png",objectId] contentType:@"image/png"];                 }


I truly don't know what to do... I am pretty sure that it has something to do with what the framework does when the operation finishes but I cannot see what it is. The stack informs me that the bad access comes from a queue :

com.apple.root.default-priority
0 ____NSOQSchedule_block_invoke_0
4 _pthread_wqthread

Here is a snapshot of a crash report if that can help :
Incident Identifier: 33F9096B-0C2A-4C9F-A83E-375E3405F101 CrashReporter Key:   aa7498c8b20065b9dc7de94160ca06ff914d8d37 Hardware Model:      iPhone5,2 Process:         arcgisproto [666] Path:            /var/mobile/Applications/C89651E3-5F52-4E55-94D0-8B31FDBEA2F8/arcgisproto.app/arcgisproto Identifier:      arcgisproto Version:         ??? (???) Code Type:       ARM (Native) Parent Process:  launchd [1]  Date/Time:       2013-05-29 10:23:03.727 +1100 OS Version:      iOS 6.0.1 (10A525) Report Version:  104  Exception Type:  EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x6b42a90d Crashed Thread:  7  Thread 0 name:  Dispatch queue: com.apple.main-thread Thread 0: 0   libobjc.A.dylib                0x3911e5cc 0x3911b000 + 13772 1   UIKit                          0x339249ba 0x338d7000 + 317882 2   UIKit                          0x33924090 0x338d7000 + 315536 3   UIKit                          0x33923ca4 0x338d7000 + 314532 4   UIKit                          0x33bfe02a 0x338d7000 + 3305514 5   UIKit                          0x338e7656 0x338d7000 + 67158 6   UIKit                          0x338e6f06 0x338d7000 + 65286 7   UIKit                          0x338e6e80 0x338d7000 + 65152 8   UIKit                          0x338e6e4a 0x338d7000 + 65098 9   UIKit                          0x338e6e0e 0x338d7000 + 65038 10  AppSupport                     0x386353e2 0x38632000 + 13282 11  CoreFoundation                 0x3a09f3e4 0x3a008000 + 619492 12  CoreFoundation                 0x3a09f386 0x3a008000 + 619398 13  CoreFoundation                 0x3a09e20a 0x3a008000 + 614922 14  CoreFoundation                 0x3a011238 0x3a008000 + 37432 15  CoreFoundation                 0x3a0110c4 0x3a008000 + 37060 16  GraphicsServices               0x3a16d336 0x3a168000 + 21302 17  UIKit                          0x3392e28c 0x338d7000 + 357004 18  arcgisproto                    0x000b21da 0xb1000 + 4570 19  libdyld.dylib                  0x39988b1c 0x39987000 + 6940  Thread 1 name:  Dispatch queue: com.apple.libdispatch-manager Thread 1: 0   libsystem_kernel.dylib         0x39e245d0 0x39e23000 + 5584 1   libdispatch.dylib              0x32eb7d22 0x32eb1000 + 27938 2   libdispatch.dylib              0x32eb3374 0x32eb1000 + 9076  Thread 2 name:  WebThread Thread 2: 0   libsystem_kernel.dylib         0x39e23e30 0x39e23000 + 3632 1   libsystem_kernel.dylib         0x39e23fd0 0x39e23000 + 4048 2   CoreFoundation                 0x3a09f2b6 0x3a008000 + 619190 3   CoreFoundation                 0x3a09e02c 0x3a008000 + 614444 4   CoreFoundation                 0x3a011238 0x3a008000 + 37432 5   CoreFoundation                 0x3a0110c4 0x3a008000 + 37060 6   WebCore                        0x34eb1a58 0x34ea7000 + 43608 7   libsystem_c.dylib              0x333af0de 0x3339e000 + 69854 8   libsystem_c.dylib              0x333aefa4 0x3339e000 + 69540  [...] Truncated because message was > 10000 chars [...]  Thread 7 name:  Dispatch queue: com.apple.root.default-priority Thread 7 Crashed: 0   Foundation                     0x32a83708 0x329e4000 + 653064 1   libdispatch.dylib              0x32eb2790 0x32eb1000 + 6032 2   libdispatch.dylib              0x32eb6652 0x32eb1000 + 22098 3   libdispatch.dylib              0x32eb67d4 0x32eb1000 + 22484 4   libsystem_c.dylib              0x333a47ee 0x3339e000 + 26606 5   libsystem_c.dylib              0x333a4680 0x3339e000 + 26240  Thread 8 name:  com.apple.NSURLConnectionLoader Thread 8: 0   libsystem_kernel.dylib         0x39e23f38 0x39e23000 + 3896 1   libsystem_c.dylib              0x333bf974 0x3339e000 + 137588 2   CFNetwork                      0x32c5e4b8 0x32c4b000 + 79032 3   CoreFoundation                 0x3a09f8f4 0x3a008000 + 620788 4   CoreFoundation                 0x3a09f158 0x3a008000 + 618840 5   CoreFoundation                 0x3a09df2a 0x3a008000 + 614186 6   CoreFoundation                 0x3a011238 0x3a008000 + 37432 7   CoreFoundation                 0x3a0110c4 0x3a008000 + 37060 8   Foundation                     0x32a11098 0x329e4000 + 184472 9   Foundation                     0x32a94a3c 0x329e4000 + 723516 10  libsystem_c.dylib              0x333af0de 0x3339e000 + 69854 11  libsystem_c.dylib              0x333aefa4 0x3339e000 + 69540  Thread 9 name:  com.apple.CFSocket.private Thread 9: 0   libsystem_kernel.dylib         0x39e34594 0x39e23000 + 71060 1   CoreFoundation                 0x3a0a3474 0x3a008000 + 636020 2   libsystem_c.dylib              0x333af0de 0x3339e000 + 69854 3   libsystem_c.dylib              0x333aefa4 0x3339e000 + 69540  Thread 10: 0   libsystem_kernel.dylib         0x39e3408c 0x39e23000 + 69772 1   libsystem_c.dylib              0x333a7afc 0x3339e000 + 39676 2   libsystem_c.dylib              0x333b1cf8 0x3339e000 + 81144 3   arcgisproto                    0x005036f8 0xb1000 + 4531960 4   libsystem_c.dylib              0x333af0de 0x3339e000 + 69854 5   libsystem_c.dylib              0x333aefa4 0x3339e000 + 69540  Thread 11: 0   libsystem_kernel.dylib         0x39e3408c 0x39e23000 + 69772 1   libsystem_c.dylib              0x333a7afc 0x3339e000 + 39676 2   libsystem_c.dylib              0x333b1cf8 0x3339e000 + 81144 3   arcgisproto                    0x005036f8 0xb1000 + 4531960 4   libsystem_c.dylib              0x333af0de 0x3339e000 + 69854 5   libsystem_c.dylib              0x333aefa4 0x3339e000 + 69540  Thread 12 name:  com.apple.coremedia.player.async Thread 12: 0   libsystem_kernel.dylib         0x39e3408c 0x39e23000 + 69772 1   libsystem_c.dylib              0x333a7afc 0x3339e000 + 39676 2   libsystem_c.dylib              0x333b1cf8 0x3339e000 + 81144 3   CoreMedia                      0x335d48b4 0x335d1000 + 14516 4   MediaToolbox                   0x32fcceaa 0x32fc9000 + 16042 5   CoreMedia                      0x335f2978 0x335d1000 + 137592 6   libsystem_c.dylib              0x333af0de 0x3339e000 + 69854 7   libsystem_c.dylib              0x333aefa4 0x3339e000 + 69540  Thread 13: 0   libsystem_kernel.dylib         0x39e34d98 0x39e23000 + 73112 1   libsystem_c.dylib              0x333a4ad6 0x3339e000 + 27350 2   libsystem_c.dylib              0x333a47f2 0x3339e000 + 26610 3   libsystem_c.dylib              0x333a4680 0x3339e000 + 26240  Thread 14: 0   libsystem_kernel.dylib         0x39e34d98 0x39e23000 + 73112 1   libsystem_c.dylib              0x333a4ad6 0x3339e000 + 27350 2   libsystem_c.dylib              0x333a47f2 0x3339e000 + 26610 3   libsystem_c.dylib              0x333a4680 0x3339e000 + 26240  Thread 7 crashed with ARM Thread State (32-bit):     r0: 0x1ed2e4f0    r1: 0x00000000      r2: 0x3a07c46d      r3: 0x0000005d     r4: 0x0000000d    r5: 0x6b42a909      r6: 0x6b42a909      r7: 0x065baf68     r8: 0x1ed2d910    r9: 0x00000004     r10: 0x3a07c46d     r11: 0x00000004     ip: 0x00000058    sp: 0x065baef0      lr: 0x00000020      pc: 0x32a83708   cpsr: 0x60000030


I tried with the attachment manager, same result. I am stuck.
Christophe.
0 Kudos
1 Solution

Accepted Solutions
ChristopheFondacci
New Contributor II
Well, just found the fix !

Just in case others made the same as me :

I was first calling :
NSOperation *nsOp = [_featureLayer addFeatures:submittedGraphics];


And then sending attachements inside the "didFeatureEditsWithResults" callback. The problem was that I was manually starting the nsOp of the addFeatures because sometimes, it does not start - other bug fixed here http://forums.arcgis.com/threads/80488-Potential-ARC-problem-with-AGSRequestOperation-sharedOperatio....

Those 2 problems were very confusing :
Because of the NSOperationQueue bug (from the other forum thread), the operation did not start, and so in this case the [nsOp start] was fixing the issue.
But as soon as I fixed this, the [nsOp start] is causing the EXC_BAD_ACCESS when a second operation terminates.

I think that maybe, since the NSOperation is a specific ArcGis implementation, you could enforce safety by not allowing to start the operation if already enqueued...

Hope this helps.
Christophe.

View solution in original post

0 Kudos
1 Reply
ChristopheFondacci
New Contributor II
Well, just found the fix !

Just in case others made the same as me :

I was first calling :
NSOperation *nsOp = [_featureLayer addFeatures:submittedGraphics];


And then sending attachements inside the "didFeatureEditsWithResults" callback. The problem was that I was manually starting the nsOp of the addFeatures because sometimes, it does not start - other bug fixed here http://forums.arcgis.com/threads/80488-Potential-ARC-problem-with-AGSRequestOperation-sharedOperatio....

Those 2 problems were very confusing :
Because of the NSOperationQueue bug (from the other forum thread), the operation did not start, and so in this case the [nsOp start] was fixing the issue.
But as soon as I fixed this, the [nsOp start] is causing the EXC_BAD_ACCESS when a second operation terminates.

I think that maybe, since the NSOperation is a specific ArcGis implementation, you could enforce safety by not allowing to start the operation if already enqueued...

Hope this helps.
Christophe.
0 Kudos