Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS My New Program Crashed

L

larswik

macrumors 68000
Original poster
Sep 8, 2006
1,552
11
It worked fine on the machine I write the code on. I transferred it to my MacBook Air to test and it crashed. I don;t know how to read these to see if it even is telling me where the problem is?

Code: 
Process:         Xp Calc2 [765]
Path:            /Users/lars/Desktop/XPCalc6.app/Contents/MacOS/Xp Calc2
Identifier:      larsTest.Xp-Calc2
Version:         1.0 (2.10)
Code Type:       X86 (Native)
Parent Process:  launchd [160]

Date/Time:       2011-07-18 17:55:14.902 -0700
OS Version:      Mac OS X 10.6.7 (10J869)
Report Version:  6

Interval Since Last Report:          316665 sec
Crashes Since Last Report:           14
Per-App Interval Since Last Report:  56699 sec
Per-App Crashes Since Last Report:   5
Anonymous UUID:                      D7C0EDFD-57DA-45F3-8A2B-487D0AFEC29F

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: aString != nil'
*** Call stack at first throw:
(
	0   CoreFoundation                      0x9349f6ba __raiseError + 410
	1   libobjc.A.dylib                     0x9746d509 objc_exception_throw + 56
	2   CoreFoundation                      0x9349f3e8 +[NSException raise:format:arguments:] + 136
	3   Foundation                          0x94722ae7 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 116
	4   AppKit                              0x908bf3f4 -[NSCell _objectValue:forString:errorDescription:] + 183
	5   AppKit                              0x908bf335 -[NSCell _objectValue:forString:] + 56
	6   AppKit                              0x908bf28a -[NSCell setStringValue:] + 56
	7   AppKit                              0x90985d7c -[NSControl setStringValue:] + 126
	8   Xp Calc2                            0x0000562e 0x0 + 22062
	9   Xp Calc2                            0x0000270e 0x0 + 9998
	10  CoreFoundation                      0x934379b4 -[NSSet makeObjectsPerformSelector:] + 196
	11  AppKit                              0x9089621c -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] + 1566
	12  AppKit                              0x908941f4 loadNib + 257
	13  AppKit                              0x908935ed +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] + 228
	14  AppKit                              0x908934fe +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] + 158
	15  AppKit                              0x90893449 +[NSBundle(NSNibLoading) loadNibNamed:owner:] + 383
	16  AppKit                              0x9089024d NSApplicationMain + 434
	17  Xp Calc2                            0x00002295 0x0 + 8853
	18  ???                                 0x00000002 0x0 + 2
)

It's some issue with an NSString != nil I think I saw, but how do I find out where?

-Lars
 
If you look down the stack trace, you can see what was executing. Lines 0-3 are about dealing with the exception itself, so you can ignore those. Lines 4-7 about setting the string value of a control. What kind of control or which control we don't know yet.

The really important lines are line 8-9, because these are methods that you've written. Unfortunately the debug symbols are missing from you app, and the stack trace only list the address of the method, which is no good.

If you continue read down, you'll see the a NIB file was trying to be loaded, probably MainMenu.xib. I would guess then that line 9 is your app delegate's awakeFromNib.

How did you get the app from your development machine to your MacBook Air? If we can get a debug build transferred across, the stack trace should tell us what methods are being called in lines 8 and 9.
 
When I made a version for my MacBook Air I went up to Build For and selected Build for Archive. Then I brought up the Archive Window and selected the latest build and selected the the SHARE button and then picked 'Application' option.

That is how I have been doing it and my friends have been seeing the app just fine. I guess it is a good thing that I am going through this so I can learn. The whole project is like 800 lines of code right now.

I have used the debugger before to walk through the program but I am unfamiliar with the app. You mentioned this "Unfortunately the debug symbols are missing from you app, and the stack trace only list the address of the method, which is no good." Can I turn the symbols on to better find the problem?

By the way, Here is a video I made with this on going project so you can see what it is. This is just telling my friends how to use it. http://sbtraveler.tv/xpCalc/XP_calc.mov It's evolved from last week which is this video.
 
I'm away from my Mac so I can't come up with exact instructions. But what might want to try is:

  1. Go into the organizer in XCode.
  2. Projects tab
  3. Select your project
  4. Click the arrow to open the Derived Data path in Finder
  5. Go into Build/Products/Debug
  6. Zip up the version of the app in the debug directory
  7. Unzip the app on your MacBook Air
  8. Run
 
Hi Jim, I followed the steps you outlined and it crashed again.

Here is what the new crash report says

Code: 
Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: aString != nil'
*** Call stack at first throw:
(
	0   CoreFoundation                      0x9349f6ba __raiseError + 410
	1   libobjc.A.dylib                     0x9746d509 objc_exception_throw + 56
	2   CoreFoundation                      0x9349f3e8 +[NSException raise:format:arguments:] + 136
	3   Foundation                          0x94722ae7 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 116
	4   AppKit                              0x908bf3f4 -[NSCell _objectValue:forString:errorDescription:] + 183
	5   AppKit                              0x908bf335 -[NSCell _objectValue:forString:] + 56
	6   AppKit                              0x908bf28a -[NSCell setStringValue:] + 56
	7   AppKit                              0x90985d7c -[NSControl setStringValue:] + 126
	8   Xp Calc2                            0x0000760c -[AppController loadPrefsAtStart] + 892
	9   Xp Calc2                            0x0000297c -[AppController awakeFromNib] + 1564
	10  CoreFoundation                      0x934379b4 -[NSSet makeObjectsPerformSelector:] + 196
	11  AppKit                              0x9089621c -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] + 1566
	12  AppKit                              0x908941f4 loadNib + 257
	13  AppKit                              0x908935ed +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] + 228
	14  AppKit                              0x908934fe +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] + 158
	15  AppKit                              0x90893449 +[NSBundle(NSNibLoading) loadNibNamed:owner:] + 383
	16  AppKit                              0x9089024d NSApplicationMain + 434
	17  Xp Calc2                            0x000022eb main + 43
	18  Xp Calc2                            0x00002275 start + 53
)
 

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation      	0x934eaa37 ___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ + 7
1   libobjc.A.dylib               	0x9746d509 objc_exception_throw + 56
2   com.apple.CoreFoundation      	0x9349f3e8 +[NSException raise:format:arguments:] + 136
3   com.apple.Foundation          	0x94722ae7 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 116
4   com.apple.AppKit              	0x908bf3f4 -[NSCell _objectValue:forString:errorDescription:] + 183
5   com.apple.AppKit              	0x908bf335 -[NSCell _objectValue:forString:] + 56
6   com.apple.AppKit              	0x908bf28a -[NSCell setStringValue:] + 56
7   com.apple.AppKit              	0x90985d7c -[NSControl setStringValue:] + 126
8   larsTest.Xp-Calc2             	0x0000760c -[AppController loadPrefsAtStart] + 892
9   larsTest.Xp-Calc2             	0x0000297c -[AppController awakeFromNib] + 1564
10  com.apple.CoreFoundation      	0x934379b4 -[NSSet makeObjectsPerformSelector:] + 196
11  com.apple.AppKit              	0x9089621c -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] + 1566
12  com.apple.AppKit              	0x908941f4 loadNib + 257
13  com.apple.AppKit              	0x908935ed +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] + 228
14  com.apple.AppKit              	0x908934fe +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] + 158
15  com.apple.AppKit              	0x90893449 +[NSBundle(NSNibLoading) loadNibNamed:owner:] + 383
16  com.apple.AppKit              	0x9089024d NSApplicationMain + 434
17  larsTest.Xp-Calc2             	0x000022eb main + 43
18  larsTest.Xp-Calc2             	0x00002275 start + 53

Thread 1:  Dispatch queue: com.apple.libdispatch-manager
0   libSystem.B.dylib             	0x94c28922 kevent + 10
1   libSystem.B.dylib             	0x94c2903c _dispatch_mgr_invoke + 215
2   libSystem.B.dylib             	0x94c284f9 _dispatch_queue_invoke + 163
3   libSystem.B.dylib             	0x94c2829e _dispatch_worker_thread2 + 240
4   libSystem.B.dylib             	0x94c27d21 _pthread_wqthread + 390
5   libSystem.B.dylib             	0x94c27b66 start_wqthread + 30

Thread 2:
0   libSystem.B.dylib             	0x94c279b2 __workq_kernreturn + 10
1   libSystem.B.dylib             	0x94c27f48 _pthread_wqthread + 941
2   libSystem.B.dylib             	0x94c27b66 start_wqthread + 30

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x00000000  ebx: 0x9746d4e5  ecx: 0xa0582540  edx: 0x0000003b
  edi: 0xa08f4af0  esi: 0x00313160  ebp: 0xbffff4f8  esp: 0xbffff4e0
   ss: 0x0000001f  efl: 0x00000282  eip: 0x934eaa37   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0x2c692000

Binary Images:
 
I omitted the new code from the awakeFromNib using the // to test it and it worked.
Code: 
[self loadPrefsAtStart];

The problem is in here. I will try to narrow it down.

Code: 
-(void)loadPrefsAtStart{
    filemgr = [NSFileManager defaultManager];
    fileSavePath = [@"~/Documents/XPCalc.plist" stringByExpandingTildeInPath]; // Sets up the default path to the file.

    if ([filemgr fileExistsAtPath: fileSavePath ] == YES){
        skills = [[NSMutableDictionary alloc] initWithContentsOfFile: fileSavePath]; // it reads the file into the Dictionary
        for (NSString *i in skills) {         //  for loop to loop through the keys if the Dictionary and add to popUpButton
            [popUpButtonDisplay addItemWithTitle: i];
        }
    }
    else {
        skills = [[NSMutableDictionary alloc] init];
        [skills writeToFile: fileSavePath atomically:YES]; // if it can't find it, it writes a blank file.
    }
    
    [doaPrefField setStringValue:[ prefs stringForKey: @"doaPrefSave"]]; // reads in the NSUserDefault pref.
    [filemgr release];
    
    
}
 
You don't own the NSFileManager you send release to. That's bad. The setStringValue just before that is where you crash. What is prefs?

-Lee

Edit: Your sig should read "than".

Edit 2: What happens on your main machine with/without the plist existing? On the MBA?
 
Last edited:
Lee I was just about to post that I found the problem area and that was it. I just read in my book the other night about 'NSUserDefaults' prefs was this 'NSUserDefaults *prefs;' So I could have some setting remembered.

I'll reread that section again but it was working ok yesterday. I wonder what I did.


I saw this piece of code last night to checking to see if a file was at a location on the drive.
Code: 
NSFileManager *filemgr;
filemgr = [NSFileManager defaultManager];

if ([filemgr fileExistsAtPath: @"/tmp/myfile.txt" ] == YES)
        NSLog (@"File exists");
else
        NSLog (@"File not found");
[filemgr release];

With in the method there is a pointer declaration *filemgr;
The next code snippet looks almost like an alloc but they use defaultManager, but at the end of the code they release it [filemgr release]; so it looks like it only exists within the method.

My book had a similar code snippet 'prefs = [NSUserDefaults standardUserDefaults];' so I followed the same procedure and released it at the end. The only difference was I had my deceleration in the AppController.H and not in the method.

The code snippet was from this site.

http://www.techotopia.com/index.php/Working_with_Files_on_iOS_4_(Xcode_4)
 
You should know better than that. Did you get the NSFileManager object with one of the NARC methods?
 
Noooo, I did not not use a NARC Method :(

Odd that the code I found online did have a release. I was monkey see, monkey do at that point. That must be a bad code snippets if he released an object he did not NARC. I did remove the release for both the prefs and the fliemgr in my program and it runs great.

Dose it matter where I declare them? I have been declaring everything in my AppController.h file. But this code he declares in the method so as it leaves the method it is release automaticly. But he made the mistake of releasing an object he did not own.
Code: 
NSFileManager *filemgr;
filemgr = [NSFileManager defaultManager];

if ([filemgr fileExistsAtPath: @"/tmp/myfile.txt" ] == YES)
        NSLog (@"File exists");
else
        NSLog (@"File not found");
[filemgr release];

Is it smoother and tidier coding to declare these in the Method and then when the method exists they are removed from memory? or keep the decelerations in the header file?
 
larswik said:
LThe code snippet was from this site.

http://www.techotopia.com/index.php/Working_with_Files_on_iOS_4_(Xcode_4)
Click to expand...

That site is wrong. Very wrong.

There's this example:
Code: 
NSFileManager *filemgr;
NSData *databuffer;

filemgr = [NSFileManager defaultManager];

databuffer = [filemgr contentsAtPath: @"/tmp/myfile.txt" ];
[filemgr release];
Having stored the contents of a file in an NSData object that data may subsequently be written out to a new file using the createFileAtPath method:
Code: 
databuffer = [filemgr contentsAtPath: @"/tmp/myfile.txt" ];

[filemgr createFileAtPath: @"/tmp/newfile.txt" 
contents: databuffer attributes: nil];
[filemgr release];
The first release is wrong, because the object isn't owned by the code calling release.

The second release is even more wrong, because the object was already released (wrongly), so releasing an already-released object is really wrong. Plus the added wrongness of using an object after it was released.

In fact, essentially every use of release on the pages dealing with files and file-manager is wrong, including this one that doesn't use NSFileManager:
Code: 
NSFileHandle *file;

file = [NSFileHandle fileHandleForWritingAtPath: 
     @"/tmp/myfile.txt"];

if (file == nil)
        NSLog(@"Failed to open file");

[file closeFile];
[file release];

The misuses of release aren't confined to that page. Other pages also use release improperly. Some code samples use it correctly, but you'd have to know the rules in order to figure it out.

Also, that website is targeting iOS, not Mac OS. Sometimes there's a difference, but in the misuse of release, it's the same (i.e. wrong).

Whatever you do, do not pay money for that ebook.
 
larswik said:
Does it matter where I declare them? I have been declaring everything in my AppController.h file.

(snip)

Is it smoother and tidier coding to declare these in the Method and then when the method exists they are removed from memory? or keep the decelerations in the header file?
Click to expand...

Declare your variables locally unless you have reason to do otherwise. A reason to do otherwise is when you need a value (for example, an integer or a point to an object) across multiple methods or across multiple calls to the same method.
 
Glad your problem is fixed. Have you used the Analyze function in XCode? It is under the product menu.

It might be a good idea to try to Analyze some really bad code, perhaps the code chown33 referenced. Just to see how it works and for the education.
 
I have used the Instruments to check for memory leaks. Most of that is still way above me on hos to use. I am hoping someone comes out with, or is already out, a book on these tools that I can read upon and how to use effectively.
 
larswik said:
I have used the Instruments to check for memory leaks. Most of that is still way above me on hos to use. I am hoping someone comes out with, or is already out, a book on these tools that I can read upon and how to use effectively.
Click to expand...

Analyze is more user friendly. It will highlight the line of code with a potential problem, draw some cool lines showing program flow, then offer a fairly easy to understand explaination. It shows errors in a way similar to how build errors are shown, but will find errors when the code builds fine even though it is clearly incorrect.


It is a different tool than insturments, one won't replace the other, but I bet it would have found your error, and offered an expaination why. You should always analyze all of your code, at least until you are comfortable with everything.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back