13

I have some code that wraps an ALAsset object that is retrieved from enumerating the assets in an ALAssetLibrary. I'm getting reports of users encountering crashes with the part of the wrapper object that asks the ALAsset it contains for metadata.

The code that crashes is in this wrapper class and it simply asks for its ALAsset's metadata like so: 

[[myAlAsset defaultRepresentation] metadata];

Here is a partial stack trace that is representative of the crashes I'm seeing: 

0
CoreFoundation   CFDataGetBytePtr + 5
1
PhotoLibraryServices     __46-[PLManagedAsset adjustmentsXMPRepresentation]_block_invoke + 228
2
PhotoLibraryServices     __46-[PLManagedAsset adjustmentsXMPRepresentation]_block_invoke + 228
3
CoreData     developerSubmittedBlockToNSManagedObjectContextPerform + 88
4
CoreData     -[NSManagedObjectContext performBlockAndWait:] + 114
5
PhotoLibraryServices     -[PLManagedAsset adjustmentsXMPRepresentation] + 226
6
AssetsLibrary    __33-[ALAssetRepresentation metadata]_block_invoke + 24
7
AssetsLibrary    __53-[ALAssetRepresentationPrivate _performBlockAndWait:]_block_invoke + 68
8
CoreData     developerSubmittedBlockToNSManagedObjectContextPerform + 88
9
libdispatch.dylib    _dispatch_client_callout + 22
10
libdispatch.dylib    _dispatch_barrier_sync_f_invoke + 26
11
CoreData     -[NSManagedObjectContext performBlockAndWait:] + 106
12
AssetsLibrary    -[ALAssetsLibrary _performBlockAndWait:] + 134
13
AssetsLibrary    -[ALAssetRepresentationPrivate _performBlockAndWait:] + 176
14
AssetsLibrary    -[ALAssetRepresentation metadata] + 464

Does anyone have ideas on what may be going on? The AlAssetLibrary that underlies these assets is saved with a static reference, so it should not be getting cleaned up in memory and so I wouldn't expect the ALAsset to have been invalidated. This issue seems to have started specifically with iOS 7 being released.

The crash itself is EXC_BAD_ACCESS with KERN_INVALID_ADDRESS at 0x0.

user1118321
  • 25,567
  • 4
  • 55
  • 86
Faisal
  • 297
  • 2
  • 16
  • We're seeing this recently as well. Looking at the `CFDataGetBytePtr` at top of the stack, I feel this might be memory-related. Have you found the cause/solution for this? – John Estropia Jan 27 '14 at 06:19
  • I'm also seeing this crash in the wild on an iPhone 4S, though I haven't been able to reproduce it. Crashlytics _is_ reporting that the device which crashed had about 45MB of RAM available around when it crashed. It's not necessarily accurate, I'm sure, but just another data point. – Rizwan Sattar Jan 27 '14 at 22:47
  • As additional info, our logs indicate that this occurs in other device models as well (not just iPhone 4S). But definitely only iOS 7.0 and above. – John Estropia Jan 31 '14 at 01:09
  • Does this happen only for images taken using the camera? – odukku Mar 12 '14 at 11:20
  • In our case we will never know. We only see this crash from our log files and could not reproduce it on our side. If helps, our app only loads assets from `ALAssetsGroupSavedPhotos` and `ALAssetsGroupAlbum` so we can rule out the photo stream and other special folders. – John Estropia Mar 13 '14 at 07:44
  • 3
    Whoa! it goes on reading XMP data which are XML strings. This is a hidden metadata property and happens in retouched images. Why don't you give a try on ImageIO framework to read metadata and see if the crash is occurring. – egghese May 21 '14 at 14:03
  • I have the same problem but cannot reproduce it by myself (just analysing crash reports). Jesly, can you tell more information about reading XMP data please? I just trying to do: [[asset defaultRepresentation] metadata]; – gN0Me Aug 20 '14 at 14:08

1 Answers1

-1

This may have caused because of buffer overflows. Pls check the link of apple website which shows the buffer overflow crash report same as you have. Hope this may help you.

https://developer.apple.com/library/ios/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html#//apple_ref/doc/uid/TP40002577-SW1

shubhangi
  • 19
  • 2