small medium large xlarge

Back to: All Forums  Core Data
Generic-user-small
10 Sep 2009, 05:28
Stuart Morgan (2 posts)

Having just spent the best part of a day trying to troubleshoot the very first source code in the “Core Data” book (Chapter 2 - GrokkingRecipes v1…!?), I’ve learned that the code compiles and runs fine in OS X 10.5, and the problems I’ve been having ONLY occur in OS X 10.6.

Specifically, the simple core data app is designed to allow you to import an imagePath whereupon the code copies an image file to a support folder and stores the path in the data model - I faithfully reproduced each of the steps and everything worked well except for the image import function. Nearly(!?) every time I imported an image, the app crashed straight after the NSOpenPanel object closed - presumably at the point the model is adding the new image path. The console information was not that helpful, and I’m not familiar enough with XCode to know more detailed ways of debugging. For what its worth, here is the console output:

[Session started at 2009-09-10 15:09:54 +1000.]
GNU gdb 6.3.50-20050815 (Apple version gdb-1344) (Fri Jul  3 01:19:56 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".tty /dev/ttys000
Loading program into debugger…
Program loaded.
run
[Switching to process 26500]
Running…
Program received signal:  “EXC_BAD_ACCESS”.
sharedlibrary apply-load-rules all

Anyway, after some fruitless error checking, I downloaded the complete app from the supplied source code and it ran fine - in OS X 10.5, but the same errors occurred if I tried to recompile in 10.6.

So, is anyone aware of what may have changed in the Snow Leopard update?

I had to change a couple of lines of code that had been deprecated in the 10.6 SDK in order for it to compile without errors or warnings - namely:

 [[NSFileManager defaultManager] copyPath:path toPath:destPath handler:nil];

to..

 NSError *error = nil;
 [[NSFileManager defaultManager] copyItemAtPath:path toPath:destPath error:&error];

…but otherwise no change.

Any thoughts would be appreciated.

Generic-user-small
12 Sep 2009, 17:30
Warren Dodge (1 post)

If the code is never adding images, check for a typo in the line:

SEL select = @selector(addImageSheetDidEnd:returnCode:contextInfo:);

and the declaration of the method:

@- (void)addImageSheetDidEnd:(NSOpenPanel *)openPanel returnCode:(NSInteger)returnCode contextInfo:(NSManagedObject *)recipe@

If it happens only sometimes, it may be a permission issue or a problem with particular image files. Also, try running from an administrator account if your is not one.

–Warren

Avatarsmall_pragsmall
13 Sep 2009, 04:23
Marcus S. Zarra (284 posts)

The same project works fine under Snow Leopard and in fact most of this book was written on Snow Leopard :)

I would check your code and see if there is a typo somewhere. Bad access exceptions usually mean an overrelease or accessing an object after it has been released.

Generic-user-small
16 Sep 2009, 00:44
Stuart Morgan (2 posts)

Hmmm, Thanks for the replies. I’m no closer to a solution, and am starting to wonder if there is some other sort of gremlin in my system/configuration?

On other non-core data projects, ANY reference to the NSOpenPanel object causes intermittent errors as reported above. I wrote the simplest application to run an openPanel from a menu item, and on my main machine (10.6, 2.33GHz, 3GB RAM), I get the dreaded “EXC_BAD_ACCESS”, but on another machine (same specs) no problem? Both are compiling in debug mode (10.6 x86_64).
- (IBAction)TryMenu:(id)sender
{
	NSOpenPanel *panel = [NSOpenPanel openPanel];
	int result = [panel runModal];
	if (result == NSOKButton) {
		NSLog(@"File = %@", [panel filename]);
	}
	return;
}

</code>

So running this once with garbage collection off gives me the “EXC_BAD_ACCESS”, but recompiling with GC=on I am getting the following message after the routine above is called several times over…

Program received signal:  “EXC_BAD_ACCESS”.
sharedlibrary apply-load-rules all
No memory available to program now: unsafe to call malloc
Data Formatters temporarily unavailable, will re-try after a 'continue'. (Not safe to call dlopen at this time.)

</code>

Obviously sounds like an object allocation problem (accessing a freed resource?), but shouldn’t the autorelease deal with everything in the TryMenu routine?

Ok, I’m quite new to cocoa (10yrs as a vb/c/c++ pc developer though), and I apologise that this is no longer a core data query… but any help would be greeted with eternal thanks.

Stuart

Avatarsmall_pragsmall
20 Sep 2009, 14:57
Marcus S. Zarra (284 posts)

If the code runs on a different machine with 10.6 but not this one that would point to a problem outside of the code. You might want to consider taking it into an Apple store and having a Genius run their diag tools on the machine.

Generic-user-small
01 Oct 2009, 05:13
Eli Boaz (1 post)

I’m also using 10.6 (10A432). I’m not sure if I ran into the same issue as Stuart, but the fix suggested by Warren (note: thanks!) did fix the ability to add an image to the database for me. I had misread the @selector(…) line in the -addImage: method.

You must be logged in to comment