I have a little CLT for copying and pasting images, written in Objective-C++. Until recently, this program compiled and ran as intended – but only just now, it seems, it has started crashing in the call to [NSApplication sharedApplication].
The stack traces indicate that the crash happens when NSApplication initializes an NSUserDefaults instance, which ends up calling a CFDictionary-related function (i.e. CFDictionarySetValue) which then crashes in free… but from within libjemalloc.
Here’s an example stack trace:
- Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libjemalloc.2.dylib 0x000000010e7b4ec5 free + 164
1 libjemalloc.2.dylib 0x000000010e7e3d50 zone_free + 168
2 com.apple.CoreFoundation 0x00007fffc5a912c5 __CFBasicHashRehash + 3461
3 com.apple.CoreFoundation 0x00007fffc5a96927 __CFBasicHashAddValue + 103
4 com.apple.CoreFoundation 0x00007fffc5a97a3d CFDictionarySetValue + 221
5 com.apple.CoreFoundation 0x00007fffc5c467da __63-[_CFXPreferences(SearchListAdditions) withSnapshotSearchList:]_block_invoke + 554
6 com.apple.CoreFoundation 0x00007fffc5c4710f -[_CFXPreferences(SearchListAdditions) withSearchLists:] + 79
7 com.apple.CoreFoundation 0x00007fffc5c4655b -[_CFXPreferences(SearchListAdditions) withSnapshotSearchList:] + 155
8 com.apple.CoreFoundation 0x00007fffc5ad08bb __CFXPreferencesCopyCurrentApplicationState + 123
9 com.apple.CoreFoundation 0x00007fffc5ad04dc _CFLocaleCopyCurrentGuts + 268
10 com.apple.CoreFoundation 0x00007fffc5ad0399 +[NSLocale currentLocale] + 9
11 com.apple.Foundation 0x00007fffc7508026 -[NSUserDefaults(NSUserDefaults) init] + 1589
12 com.apple.Foundation 0x00007fffc7507995 +[NSUserDefaults(NSUserDefaults) standardUserDefaults] + 81
13 com.apple.AppKit 0x00007fffc35c9254 +[NSApplication initialize] + 90
14 libobjc.A.dylib 0x00007fffda9b0b04 CALLING_SOME_+initialize_METHOD + 19
15 libobjc.A.dylib 0x00007fffda9a16b9 _class_initialize + 579
16 libobjc.A.dylib 0x00007fffda9a105b lookUpImpOrForward + 240
17 libobjc.A.dylib 0x00007fffda9a0ad4 _objc_msgSend_uncached + 68
18 impaste 0x0000000106197198 void objc::run_thread<AXDryRunThread>(NSDictionary*) + 120
19 impaste 0x0000000106196820 main + 2608
20 libdyld.dylib 0x00007fffdb294235 start + 1
… This last bit is most curious as I am not using the JeMalloc library. Neither my CLT program nor the libraries on which it is built have anything to do with JeMalloc, and the build system doesn’t currently reference it at all. I don’t include anything from, or link anything to, the JeMalloc library at any point whatsoever.
However: from the stack trace, it looks like the CoreFoundation libraries I am using are, in fact, using JeMalloc.
I don’t know much about JeMalloc, but I do believe that it provides a global drop-in replacement for malloc and free (in addition to furnishing a host of custom, fine-grained memory-management functions).
My call to [NSApplication sharedApplication] (as seen on line #18 of the stack trace above) looks like this:
template <typename OCThreadType> inline
void run_thread(NSDictionary* options = #{}) {
#autoreleasepool {
[NSApplication sharedApplication];
[[[OCThreadType alloc] initWithOptions:options] start];
AXAppDelegate* delegate = [[AXAppDelegate alloc] init];
NSApp.delegate = delegate;
[NSApp run];
};
}
Can anyone shed some light on this? What could cause this program to crash in this fashion (and specifically, what may have changed recently in CoreFoundation)?
Related
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.
I'm seeing a strange crash in one of my apps that seems to be coming from a private method on UIAlertView. I've down some searching and found a few other references to this method being involved in crashes such as here, but I'm not convinced that the cause is the same. However to be certain made sure that I always set the UIAlertView delegate to nil whenever the delegate is deallocated.
The stack trace is as follows:
Exception Type: SIGABRT
Exception Codes: #0 at 0x351ce32c
Crashed Thread: 0
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x351ce32c __pthread_kill + 8
1 libsystem_c.dylib 0x370c329f abort + 95
2 eLogbook 0x000bbacd -[GetOperationPartsDictionary init] (GetOperationPartsDictionary.m:22)
3 UIKit 0x32557f93 -[UIAlertView(Private) _popoutAnimationDidStop:finished:] + 855
4 UIKit 0x3240dc53 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 471
5 UIKit 0x3241357d -[UIViewAnimationState animationDidStop:finished:] + 53
6 QuartzCore 0x36eeac2f CA::Layer::run_animation_callbacks(void*) + 203
7 libdispatch.dylib 0x3140ae91 _dispatch_main_queue_callback_4CF$VARIANT$up + 197
8 CoreFoundation 0x353ad2ad __CFRunLoopRun + 1269
9 CoreFoundation 0x353304a5 CFRunLoopRunSpecific + 301
10 CoreFoundation 0x3533036d CFRunLoopRunInMode + 105
11 GraphicsServices 0x3662c439 GSEventRunModal + 137
12 UIKit 0x32426e7d UIApplicationMain + 1081
13 eLogbook 0x0007767f main (main.m:14)
The thing that is really confusing me about this is that the -[UIAlertView(Private) _popoutAnimationDidStop:finished:] method appears to be calling the init method on my GetOperationPartsDictionary class. From the limited amount of information I've had from users this crash is happening on startup, at which point that class would not have been loaded.
I'm using QuincyKit to deliver the crash reports to a server, from there they're symbolicated using the standard symbolicatecrash script. The version of Xcode being used to symbolicate the crash is the same version that was used to build the binary, and I'm confident that the dSYM used to symbolicate the crash is the correct one - the line numbers for my code are correct for example.
Anyone have any thoughts on this?
Edit: should have added that this is occurring in the field with a live app, but only occasionally. It has affected maybe 1 or 2 users in a thousand or so, but I have never been able to reproduce it either on a device or in the simulator.
Looks like you have called the UIAlertViewDelegate after the alertview has been released.
Release it only in the dealloc method like this :
-(void)dealloc {
self.alertView.delegate = nil; //setting delegate to nil
self.alertView = nil; //if you have defined alert as property
//other release statements of your controller
[super dealloc];
}
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.
My app works great when I build and debug but when I run on its own, it crashes due to some other issues.
I have one NSObject class, one UITableView class, one UIView class , one UITableViewCell class and one NSOperation class.
Does any body have similar issues or if any one can help me out.
Application Specific Information:
objc_msgSend() selector name: release
iPhone Simulator 235, iPhone OS 4.2 (iPhone/8C134)
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x01134a67 objc_msgSend + 27
1 UIKit 0x004ab1e2 -[UITableViewCell removeFromSuperview] + 167
2 UIKit 0x003249d9 -[UIView dealloc] + 340
3 UIKit 0x0032e281 -[UIScrollView dealloc] + 341
4 UIKit 0x003661ce -[UITableView dealloc] + 1085
5 Foundation 0x000698da __delayedPerformCleanup + 59
6 CoreFoundation 0x00f4bbde CFRunLoopTimerInvalidate + 446
7 CoreFoundation 0x00fb57d7 __CFRunLoopDoTimer + 1799
8 CoreFoundation 0x00f11cc9 __CFRunLoopRun + 1817
9 CoreFoundation 0x00f11240 CFRunLoopRunSpecific + 208
10 CoreFoundation 0x00f11161 CFRunLoopRunInMode + 97
11 GraphicsServices 0x01874268 GSEventRunModal + 217
12 GraphicsServices 0x0187432d GSEventRun + 115
13 UIKit 0x002fa42e UIApplicationMain + 1160
14 Time 0x00001e08 main + 102 (main.m:14)
15 Time 0x00001d99 start + 53
This technote has the technical info on crashlogs:
http://developer.apple.com/library/mac/#technotes/tn2004/tn2123.html
However, you are having a debugging problem, not a crashlog problem.
See tips for debugging here:
http://www.cocoadev.com/index.pl?DebuggingTechniques
Interpreting crash logs takes practice. People here see this: removeFromSuperview and immediately think "Aha, a clue! this is likely a memory issue" because removeFromSuperview will remove a view then decrement it's retain count. if the retain count is already zero, then decrementing one more time may lead to a crash. Thus, they think you are over releasing your UITableViewCell
check your UITableViewCell for alloc/init, release or autorelease...
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!