iPad App crashes only when it is launched manually (from springboard). Memory issue suspected - iphone

I have been trying to solve this problem for 2 days now and it is driving me crazy. When Xcode launches the app it works fine, but If I manually launch the app from Springboard it crashes. The console prints out this:
Jan 20 15:26:29 unknown UIKitApplication:com.yourcompany.ThinClient[0x28cf][1119] <Notice>: ThinClient(1119,0x3db0000) malloc: *** error for object 0x643434: incorrect checksum for freed object - object was probably modified after being freed.
Jan 20 15:26:29 unknown UIKitApplication:com.yourcompany.ThinClient[0x28cf][1119] <Notice>: *** set a breakpoint in malloc_error_break to debug
Jan 20 15:26:29 unknown ThinClient[1119] <Error>: ThinClient(1119,0x3db0000) malloc: *** error for object 0x643434: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
The stack for the crashed thread (usually) looks like this, although sometimes it crashes in different spots:
Thread 5 Crashed:
0 libsystem_kernel.dylib 0x33d4da1c __pthread_kill + 8
1 libsystem_c.dylib 0x353523b4 pthread_kill + 52
2 libsystem_c.dylib 0x3534abf8 abort + 72
3 libsystem_c.dylib 0x3535e822 szone_error + 210
4 libsystem_c.dylib 0x3535e920 free_list_checksum_botch + 16
5 libsystem_c.dylib 0x35361722 tiny_malloc_from_free_list + 82
6 libsystem_c.dylib 0x35361e76 szone_malloc_should_clear + 166
7 libsystem_c.dylib 0x35362fd4 szone_malloc + 4
8 libsystem_c.dylib 0x35386230 malloc_zone_malloc + 48
9 libsystem_c.dylib 0x35386c2c malloc + 28
10 ThinClient 0x0000590c -[MySocket readBytes:] (MySocket.m:231)
11 ThinClient 0x00007b7e -[ThinServerTalker onSocket:readCallbackBytesWaiting:] (ThinServerTalker.m:362)
12 ThinClient 0x000057e2 ReadDataCB (MySocket.m:201)
13 CoreFoundation 0x33cca48a __CFSocketDoCallback + 334
14 CoreFoundation 0x33ccb4a2 __CFSocketPerformV0 + 78
15 CoreFoundation 0x33cc5a72 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 6
16 CoreFoundation 0x33cc7758 __CFRunLoopDoSources0 + 376
17 CoreFoundation 0x33cc84e4 __CFRunLoopRun + 224
18 CoreFoundation 0x33c58ebc CFRunLoopRunSpecific + 224
19 CoreFoundation 0x33c9b6d2 CFRunLoopRun + 42
20 ThinClient 0x00005656 -[MySocket _connect] (MySocket.m:160)
21 Foundation 0x33d71382 -[NSThread main] + 38
22 Foundation 0x33de35c6 __NSThread__main__ + 966
23 libsystem_c.dylib 0x3535230a _pthread_start + 242
24 libsystem_c.dylib 0x35353bb4 thread_start + 0
I suspect its from the application writing to memory that has already been freed, so I have already tried a few things:
I tried debugging the app with guard malloc, scribble, guard edges, zombie objects, malloc stack, etc..
I tried going to the code where the app crashed and finding an issue there ( i do not believe there is an issue there because the app crashes at different places, but they are all near each other)
I tried going through and commenting out all of my free() function calls.
I still have not found the problem! If anybody could please shed some light on this it would be much appreciated! Thanks! Any Suggestions?
Edit: The app will crash every time if it is launched from springboard, but if Xcode launches it, it will work fine.

I found the issue. I was returning a direct pointer to the bytes in a NSData object from a function. I simply replaced a function called "-(char*)getBytes" with a function called "-(NSData*)getDataCopy". Get data copy instead returns an autoreleased copy of the data class.
To reiterate:
I had this:
-(char*)getBytes{
return _data.bytes;}
and I replaced it with this
-(NSData*)getDataCopy{
return [NSData dataWithData:_data];
}
The issue was I was writing to memory that had already been released.

Related

UnityReportWWWFinishedLoadingData Xcode crash

I have been stuck on this issue for the last two days. I'm using Unity 5.2.3f1 and calling a URL through WWW(URL) class. The URL uses https so it is SSL secured. The file that I'm retrieving is a simple plist file that I've placed in my dropbox account. The call is made inside a coroutine and the result is expected in a yield statement. I've also added App Allow Transport Property in Info.plist file and allowed Arbitrary Loads true in it.
However whenever I try to retrieve the data, my app crashes halting at FeedUnityWebStream after UnityReportWWWFinishedLoadingData.
Crash log is as following:
Setting up 1 worker threads for Enlighten.
Thread -> id: 16e677000 -> priority: 1
2015-11-30 15:53:58.278 3dgymnastics[1029:280327] -[NSMallocBlock bytes]: unrecognized selector sent to instance 0x13898d260
2015-11-30 15:53:58.368 3dgymnastics[1029:280327] Uncaught exception: NSInvalidArgumentException: -[NSMallocBlock bytes]: unrecognized selector sent to instance 0x13898d260
(
0 CoreFoundation 0x0000000185b7cf60 + 148
1 libobjc.A.dylib 0x000000019a63ff80 objc_exception_throw + 56
2 CoreFoundation 0x0000000185b83c5c + 0
3 CoreFoundation 0x0000000185b80c00 + 872
4 CoreFoundation 0x0000000185a84cac _CF_forwarding_prep_0 + 92
5 3dgymnastics 0x000000010043fe08 _ZN3WWW18FeedUnityWebStreamEb + 104
6 3dgymnastics 0x00000001006796a8 UnityReportWWWFinishedLoadingData + 68
7 CFNetwork 0x000000018540f6a8 + 80
8 CFNetwork 0x000000018540f638 + 200
9 CFNetwork 0x000000018540f7ac + 56
10 CFNetwork 0x000000018527b4fc + 100
11 CFNetwork 0x0000000185369b38 + 108
12 libdispatch.dylib 0x0000000101e7dc68 _dispatch_client_callout + 16
13 libdispatch.dylib 0x0000000101e8740c _dispatch_block_invoke + 564
14 CFNetwork 0x0000000185267ce4 + 36
15 CoreFoundation 0x0000000185a606cc CFArrayApplyFunction + 68
16 CFNetwork 0x0000000185267bc8 + 136
17 CFNetwork 0x0000000185267a88 + 312
18 CFNetwork 0x00000001852678b4 + 68
19 CoreFoundation 0x0000000185b34544 + 24
20 CoreFoundation 0x0000000185b33f58 + 412
21 CoreFoundation 0x0000000185b31cd8 + 724
22 CoreFoundation 0x0000000185a60ca0 CFRunLoopRunSpecific + 384
23 GraphicsServices 0x0000000190c9c088 GSEventRunModal + 180
24 UIKit 0x000000018b178ffc UIApplicationMain + 204
25 3dgymnastics 0x0000000100053100 main + 144
26 libdyld.dylib 0x000000019ae8e8b8 + 4
)
2015-11-30 15:53:58.369 3dgymnastics[1029:280327] * Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSMallocBlock__ bytes]: unrecognized selector sent to instance 0x13898d260'
* First throw call stack:
(0x185b7cf48 0x19a63ff80 0x185b83c5c 0x185b80c00 0x185a84cac 0x10043fe08 0x1006796a8 0x18540f6a8 0x18540f638 0x18540f7ac 0x18527b4fc 0x185369b38 0x101e7dc68 0x101e8740c 0x185267ce4 0x185a606cc 0x185267bc8 0x185267a88 0x1852678b4 0x185b34544 0x185b33f58 0x185b31cd8 0x185a60ca0 0x190c9c088 0x18b178ffc 0x100053100 0x19ae8e8b8)
libc++abi.dylib: terminating with uncaught exception of type NSException
I know the problem is related to security settings recently introduced by Apple in iOS9. The work around I have been using till now is by adding NSAppTransportSecurity. However it just won't work anymore. Need help in the matter.
My Unity version is 5.2.3 and Xcode is 7.1.
Not sure if this is the correct approach but I finally managed to get it working. I was turning ARC setting off to allow few files with retain. Something I should never have done since a simple separate flags for these files in Build Phases can get it done. On turning ARC back on, the rest of the program worked without errors. Newbie or rookie mistake to make. Unity5 onwards turns on ARC by default. I guess a lot depends on it in exported Xcode project. Hopefully this helps someone if they encounter something similar.

SIGSEGV SEGV_ACCERR crash in NSFileAttributes dealloc when autoreleasepool is drained?

I'm getting a strange crash when using NSFileManager to get the file size in a background thread.
I have a property of a song object called localFileSize:
- (unsigned long long)localFileSize
{
return [[[NSFileManager defaultManager] attributesOfItemAtPath:self.currentPath error:NULL] fileSize];
}
In my class that handles my audio playback (using a 3rd party audio library, not AQS or Core Audio), there is a file length callback function that is called in the audio library's playback thread, so not the main thread.
In that file length function, I'm reading the localFileSize property of my song object, inside an #autoreleasepool. At the end of the function, when the pool is drained, there appears to sometimes be a crash with the NSFileAttributes object's dealloc method. I can't reproduce it myself, but I have 14 crash logs with this issue.
Here is the relevant portion of one of the crash logs:
Thread 8 Crashed:
0 libobjc.A.dylib 0x3262c4e8 _ZN4objc8DenseMapIP11objc_objectmLb1ENS_12DenseMapInfoIS2_EENS3_ImEEE4growEj + 67
1 libobjc.A.dylib 0x32638d81 _ZN4objc8DenseMapIP11objc_objectmLb1ENS_12DenseMapInfoIS2_EENS3_ImEEE16InsertIntoBucketERKS2_RKmPSt4pairIS2_mE + 56
2 libobjc.A.dylib 0x3262b09d _ZN4objc8DenseMapIP11objc_objectmLb1ENS_12DenseMapInfoIS2_EENS3_ImEEE16FindAndConstructERKS2_ + 44
3 libobjc.A.dylib 0x3262b139 _objc_rootReleaseWasZero + 92
4 libobjc.A.dylib 0x3262b0ad _objc_rootRelease + 12
5 Foundation 0x31fbab81 -[NSFileAttributes dealloc] + 60
6 libobjc.A.dylib 0x3262b0c5 _objc_rootRelease + 36
7 libobjc.A.dylib 0x3262cdb7 objc_release + 38
8 libobjc.A.dylib 0x3262be0d _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 224
9 libobjc.A.dylib 0x3262bd29 _objc_autoreleasePoolPop + 12
10 CoreFoundation 0x35b0ce8f _CFAutoreleasePoolPop + 18
11 Foundation 0x31f8aaf1 -[NSAutoreleasePool drain] + 128
12 iSub 0x000fb6cb MyFileLenProc (AudioEngine.m:320)
13 iSub 0x001623d8 BASS_FX_TempoCreate + 5160
14 iSub 0x0016261c BASS_FX_TempoCreate + 5740
15 iSub 0x0017f42c BASS_ChannelIsActive + 27424
16 AudioToolbox 0x364905d9 _ZN19AudioConverterChain19DirectCallInputProcEPmS0_P15AudioBufferListPPK28AudioStreamPacketDescription + 228
17 AudioToolbox 0x36465ee3 _ZN14CodecConverter13CallInputProcERm + 266
18 AudioToolbox 0x3646588d _ZN14CodecConverter17DecoderFillBufferERmR15AudioBufferListP28AudioStreamPacketDescription + 576
19 AudioToolbox 0x36465649 _ZN14CodecConverter10FillBufferERmR15AudioBufferListP28AudioStreamPacketDescription + 28
20 AudioToolbox 0x36452c99 _ZN19AudioConverterChain12RenderOutputEP12CABufferListmRmP28AudioStreamPacketDescription + 92
21 AudioToolbox 0x36452b53 _ZN22BufferedAudioConverter10FillBufferERmR15AudioBufferListP28AudioStreamPacketDescription + 186
22 AudioToolbox 0x36452929 AudioConverterFillComplexBuffer + 356
23 iSub 0x0017d9f8 BASS_ChannelIsActive + 20716
24 iSub 0x00184f70 BASS_ChannelSetPosition + 640
25 iSub 0x00186eb4 BASS_ChannelGetData + 1032
26 iSub 0x000fc787 __35-[AudioEngine keepRingBufferFilled]_block_invoke_0 (AudioEngine.m:752)
27 libdispatch.dylib 0x35e3fd55 _dispatch_call_block_and_release + 12
28 libdispatch.dylib 0x35e4b7a3 _dispatch_worker_thread2 + 262
29 libsystem_c.dylib 0x30fbb1cf _pthread_wqthread + 294
Any ideas what could be causing this?
Also, if it makes any difference, at the time these crashes were reported the project was not using ARC. I recently converted to ARC, but have not released the update yet. I don't that would make any difference in this case though anyway.
Also, it's worth noting that all of the crash reports have been from iOS 5.0.1 and 5.1, even though my app supports 4.2 and above. So potentially an iOS 5 bug of some kind?
I wonder when did that change? I clearly remember [NSFileManager defaultManager] not being thread-safe. And, by the way, we are having the same issue calling defaultManager from multiple threads as well. It looks like other people remember it the same way: http://useyourloaf.com/blog/2011/06/12/nsfilemanager-defaultmanager-is-not-thread-safe.html
Don't use the +defaultManager from background threads. Just alloc+init an instance, use it, and (if not using ARC) release it. That was just wrong.
Ended up using something like this to get file size:
#include <sys/stat.h>
struct stat fileInfo;
off_t fileSize; // Can cast to long long
stat(filename, &fileInfo);
fileSize = fileInfo.st_size;
Or you can try creating new NSFileManager objects, as it appears the docs may not be completely truthful about thread safety.

Crash on [NSURLConnection releaseDelegate] in a function without NSURLConnections, how do I culprit?

Hullo,
I am experimenting a very vicious crash that shows up in the following way in the device logs:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x50000008
Crashed Thread: 0`
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x33b24c98 objc_msgSend + 16
1 Foundation 0x3429465a _NSURLConnectionReleaseClient + 30
2 CFNetwork 0x355ac608 ClientContextHolder<CFURLConnectionClient_V4>::forget() + 20
3 CFNetwork 0x355ac5ea URLConnectionClient::releaseClientLocked() + 34
4 CFNetwork 0x355a0e9a URLConnectionClient::processEvents() + 170
5 CFNetwork 0x355a0de2 URLConnection::multiplexerClientPerform(RunLoopMultiplexer*) + 30
6 CFNetwork 0x355a0d54 MultiplexerSource::perform() + 120
7 CFNetwork 0x355a0cd2 MultiplexerSource::_perform(void*) + 2
8 CoreFoundation 0x3039ca72 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 6
9 CoreFoundation 0x3039e758 __CFRunLoopDoSources0 + 376
10 CoreFoundation 0x3039f4e4 __CFRunLoopRun + 224
11 CoreFoundation 0x3032febc CFRunLoopRunSpecific + 224
12 CoreFoundation 0x3032fdc4 CFRunLoopRunInMode + 52
13 GraphicsServices 0x35571418 GSEventRunModal + 108
14 GraphicsServices 0x355714c4 GSEventRun + 56
15 UIKit 0x358c7d62 -[UIApplication _run] + 398
16 UIKit 0x358c5800 UIApplicationMain + 664
17 inArrivo 0x000023ca main (main.m:14)
18 inArrivo 0x00002394 start + 32
After having enabled NSZombie I also have a crash on the compiler log of the following form:
2011-05-09 16:12:24.400 inArrivo[5019:707] * -[NSURLConnection releaseDelegate]: message sent to deallocated instance 0x5d61670
appearing on the app main with the last NSLog comeing from a function with no url connections. Also if I remove some pieces of very innocent code from that function, no crash occurs, and the same happens when I run the complete application on the simulator.
Could someone give me some hints about what I may do to locate the piece of code producing the crash? Normal debugging of course is of little help here.
Thanks,
Fabrizio Bartolomucci
The message indicates that the delegate for NSURLConnection was deallocated. I would suggest you check the delegate object to see if you are doing an extra release on it.

Getting strange intermittent "unrecognized selector" exceptions in iPhone app

Recently, I've been getting intermittent error reports from my app claiming "unrecognized selector" in areas that could not possibly cause them, and yet they do.
For example, this one:
Error: NSInvalidArgumentException: *** -[NSCFString didReceiveMemoryWarning]: unrecognized selector sent to instance 0x541fe0
0 CoreFoundation 0x32de1e23 __handleUncaughtException + 230
1 libobjc.A.dylib 0x3266d894 _objc_terminate + 156
2 libstdc++.6.dylib 0x338c3a8c _ZN10__cxxabiv111__terminateEPFvvE + 84
3 libstdc++.6.dylib 0x338c3b04 _ZSt9terminatev + 24
4 libstdc++.6.dylib 0x338c3c2c __cxa_throw + 108
5 libobjc.A.dylib 0x3266be5c objc_exception_throw + 112
6 CoreFoundation 0x32de2bfd -[NSObject doesNotRecognizeSelector:] + 112
7 CoreFoundation 0x32d67b19 ___forwarding___ + 480
8 CoreFoundation 0x32d5e840 _CF_forwarding_prep_0 + 48
9 Foundation 0x33f765d9 _nsnote_callback + 184
10 CoreFoundation 0x32d9e511 _CFXNotificationPostNotification + 304
11 Foundation 0x33f741b3 -[NSNotificationCenter postNotificationName:object:userInfo:] + 70
12 Foundation 0x33f76519 -[NSNotificationCenter postNotificationName:object:] + 20
13 UIKit 0x30d18db8 -[UIApplication _performMemoryWarning] + 68
14 UIKit 0x30d18d50 -[UIApplication _receivedMemoryNotification] + 136
15 UIKit 0x30d18c80 _memoryStatusChanged + 64
16 CoreFoundation 0x32d66eb7 __CFNotificationCenterDarwinCallBack + 26
17 CoreFoundation 0x32d5cb51 __CFMachPortPerform + 78
18 CoreFoundation 0x32da452b CFRunLoopRunSpecific + 2302
19 CoreFoundation 0x32da3c1f CFRunLoopRunInMode + 50
20 GraphicsServices 0x31bb9374 GSEventRunModal + 196
21 UIKit 0x30bf3c30 -[UIApplication _run] + 560
22 UIKit 0x30bf2230 UIApplicationMain + 968
23 Mind 0x00002c68 main + 72
24 Mind 0x00002be4 start + 52
This is the OS sending a memory warning to my app, and somehow the application class has changed into a string.
It seems to happen a lot more when the code is invoked via an NSOperation:
Error: NSInvalidArgumentException: -[NSCFString setObject:forKey:]: unrecognized selector sent to instance 0x3e793088
9 Mind 0x0015de70 -[CCTextureCache textureFromFile:] + 528
10 Mind 0x0015d9f4 -[CCTextureCache loadImageUncached:pixelFormat:] + 116
11 Mind 0x0015d058 -[CCTextureCache addImage:pixelFormat:] + 152
12 Mind 0x00080524 -[ImageLoader imageWithFile:pixelFormat:] + 84
13 Mind 0x000854c4 -[ImageLoadOperation performLoad] + 68
14 Mind 0x00085800 -[ResourceLoadOperation main] + 112
15 Foundation 0x30c4c8b5 -[__NSOperationInternal start] + 664
16 Foundation 0x30c4c613 -[NSOperation start] + 22
17 Foundation 0x30cbdb63 ____startOperations_block_invoke_2 + 46
18 libSystem.B.dylib 0x31227858 _dispatch_call_block_and_release + 20
19 libSystem.B.dylib 0x3122863c _dispatch_worker_thread2 + 128
20 libSystem.B.dylib 0x311b1544 _pthread_wqthread + 400
21 libSystem.B.dylib 0x311a8b74 __stack_chk_fail + 4294967295
The code in question is:
[textures setObject:texture forKey:filename];
textures is type NSMutableDictionary* and never gets reassigned or deallocated (naturally, since this is a cache object). This is the only place where setObject is invoked in this method, yet according to the stack trace, textures was a string.
I also get this weirdness:
Error: NSInvalidArgumentException: -[NSConcreteNotification getPixelFormatForIdentifier:]: unrecognized selector sent to instance 0x5c021b0
9 Mind 0x0015dd0c -[CCTextureCache textureFromFile:] + 172
10 Mind 0x0015d9f4 -[CCTextureCache loadImageUncached:pixelFormat:] + 116
11 Mind 0x0015d058 -[CCTextureCache addImage:pixelFormat:] + 152
12 Mind 0x00080524 -[ImageLoader imageWithFile:pixelFormat:] + 84
13 Mind 0x000854c4 -[ImageLoadOperation performLoad] + 68
14 Mind 0x00085800 -[ResourceLoadOperation main] + 112
15 Foundation 0x347b78b5 -[__NSOperationInternal start] + 664
16 Foundation 0x347b7613 -[NSOperation start] + 22
17 Foundation 0x34828b63 ____startOperations_block_invoke_2 + 46
18 libSystem.B.dylib 0x32a2f858 _dispatch_call_block_and_release + 20
19 libSystem.B.dylib 0x32a3063c _dispatch_worker_thread2 + 128
20 libSystem.B.dylib 0x329b9544 _pthread_wqthread + 400
21 libSystem.B.dylib 0x329b0b74 __stack_chk_fail + 4294967295
This trace is from the following code in CCTextureCache:
CCTexture2DPixelFormat pixelFormat = [self getPixelFormatForIdentifier:identifier];
How CCTextureCache changed into NSConcreteNotification after having already called a number of methods on itself is baffling to say the least.
Has anyone else noticed this sort of thing? Am I somehow getting memory corruption?
Did you check some race conditions about multi-threads ? It seems like some resource freed by another thread, and current thread send a messaged to a deallocated object.
Error: NSInvalidArgumentException: -[NSCFString setObject:forKey:]: unrecognized selector sent to instance 0x3e793088
9 Mind 0x0015de70 -[CCTextureCache textureFromFile:] + 528
10 Mind 0x0015d9f4 -[CCTextureCache loadImageUncached:pixelFormat:] + 116
11 Mind 0x0015d058 -[CCTextureCache addImage:pixelFormat:] + 152
12 Mind 0x00080524 -[ImageLoader imageWithFile:pixelFormat:] + 84
13 Mind 0x000854c4 -[ImageLoadOperation performLoad] + 68
14 Mind 0x00085800 -[ResourceLoadOperation main] + 112
15 Foundation 0x30c4c8b5 -[__NSOperationInternal start] + 664
16 Foundation 0x30c4c613 -[NSOperation start] + 22
17 Foundation 0x30cbdb63 ____startOperations_block_invoke_2 + 46
18 libSystem.B.dylib 0x31227858 _dispatch_call_block_and_release + 20
19 libSystem.B.dylib 0x3122863c _dispatch_worker_thread2 + 128
20 libSystem.B.dylib 0x311b1544 _pthread_wqthread + 400
21 libSystem.B.dylib 0x311a8b74 __stack_chk_fail + 4294967295
This is often caused by memory management errors. Did you try zombies?
...with zombies enabled, messages to deallocated objects will no longer behave
strangely or crash in difficult-to-understand ways, but will instead log a message
and die in a predictable and debugger-breakpointable way. This is the tool to use
when trying to track down over-releases and premature releases.
I just ran into the same problem, but it turns out I had made a stupid mistake:
I had declared a member like this in the header file:
NSMutableDictionary* myDict;
But then initialized it like this in the .m file:
myDict = [[NSDictionary alloc] init];
which is valid and all, because the NSMutableDictionary is derived from the NSDictionary class. Therefore all calls that are inherited from NSDictionary actually worked, but the calls specific to NSMutableDictionary [setObject: forKey:] failed because I tried to invoke them on the parent class.
The mistake was really dumb, but I was also thrown off by the fact that the debugger reported the type of myDict as something totally different (neither NSDictionary, nor NSMutableDictionary). I hope this helps some other tired coder :-)

iPad application crash in Apple review - cannot replicate in simulator, have crash log

I am clearly missing something obvious here and would really appreciate some input. I have tried repeatedly to submit an application to Apple (iPad in this case) that is crashing on their end when testing but I cannot replicated the situation on my end (obviously I only have the damned simulator to work with at this point).
The crash log is as follows:
Date/Time: 2010-04-01 05:39:47.226 -0700
OS Version: iPhone OS 3.2 (7B367)
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Thread 0 Crashed:
0 libSystem.B.dylib 0x000790a0 __kill + 8
1 libSystem.B.dylib 0x00079090 kill + 4
2 libSystem.B.dylib 0x00079082 raise + 10
3 libSystem.B.dylib 0x0008d20a abort + 50
4 libstdc++.6.dylib 0x00044a1c __gnu_cxx::__verbose_terminate_handler() + 376
5 libobjc.A.dylib 0x000057c4 _objc_terminate + 104
6 libstdc++.6.dylib 0x00042dee __cxxabiv1::__terminate(void (*)()) + 46
7 libstdc++.6.dylib 0x00042e42 std::terminate() + 10
8 libstdc++.6.dylib 0x00042f12 __cxa_throw + 78
9 libobjc.A.dylib 0x000046a4 objc_exception_throw + 64
10 CoreFoundation 0x00090c6e +[NSException raise:format:arguments:] + 74
11 CoreFoundation 0x00090d38 +[NSException raise:format:] + 28
12 Foundation 0x00002600 -[NSCFDictionary setObject:forKey:] + 184
13 iPadMosaic 0x00003282 -[iPadMosaicViewController getAlbumThumbs] (iPadMosaicViewController.m:468)
14 Foundation 0x000728fe __NSFireDelayedPerform + 314
15 CoreFoundation 0x00022d1c CFRunLoopRunSpecific + 2092
16 CoreFoundation 0x000224da CFRunLoopRunInMode + 42
17 GraphicsServices 0x000030d4 GSEventRunModal + 108
18 GraphicsServices 0x00003180 GSEventRun + 56
19 UIKit 0x000034c2 -[UIApplication _run] + 374
20 UIKit 0x000019ec UIApplicationMain + 636
21 iPadMosaic 0x00002234 main (main.m:14)
22 iPadMosaic 0x00002204 start + 32
My understanding here is that I am botching the Dictionary add somehow. The relevant lines of code are:
for (NSDictionary *album in self.albumList) {
// Get image for each album cover
UIImage *albumCover;
// Loop through photos to get URL of cover based on photo ID match
NSString *coverURL = #"";
for (NSDictionary *photo in self.photoList) {
if ([[photo objectForKey:#"pid"] isEqualToString:[album objectForKey:#"cover_pid"]]) {
coverURL = [photo objectForKey:#"src"];
}
}
NSURL *albumCoverURL = [NSURL URLWithString:coverURL];
NSData *albumCoverData = [NSData dataWithContentsOfURL:albumCoverURL];
albumCover = [UIImage imageWithData:albumCoverData];
if (albumCover == nil || albumCover == NULL) {
//NSLog(#"No album cover for some reason");
albumCover = [UIImage imageNamed:#"noImage.png"];
}
[[self.albumList objectAtIndex:albumCurrent] setObject:albumCover forKey:#"coverThumb"];
}
This is part of a loop that runs over the existing dictionaries stored in an array. If retrieving the album cover fails for some reason the object is filled with a default image and then added. The last line of the code is what's showing up in the crash log.
It runs fine in the simulator but crashes 100% in testing on device apparently. Can anyone tell me what I am missing here?
If Foundation isn't radically changed in from 3.0 to 3.2, then there's only 3 cases an exception is raised in -setObject:forKey::
mutating method sent to immutable object
attempt to insert nil value
attempt to insert nil key
Obviously the 3rd case is impossible, so you only need to check:
Is [self.albumList objectAtIndex:albumCurrent] guaranteed to be an NSMutableDictionary?
Have you forgotten to include noImage.png in submission?
I had the same problem! It was a case sensitivity issue...make sure that the file named noImage.png matches the actual file...not NoImage.png or noimage.png...check all of your images! I missed out on the app store opening because of 1 letter on 1 file!