Re: NSObject Foundation tool memory issue?
Re: NSObject Foundation tool memory issue?
- Subject: Re: NSObject Foundation tool memory issue?
- From: Niko Matsakis <email@hidden>
- Date: Thu, 8 Dec 2005 15:21:18 +0100
Well, it probably means that you released an auto-released object
without retaining it first, so that when the autorelease pool tries
to release it's ref the object has already been freed.
I know that there are tools to help you with this: Unfortunately I
don't know much about them as I haven't had a need for them yet. If
it is just a double-free, as I'm suggesting, no doubt a tool can find
it easily.
Check out this link which has information on MallocDebug and Guarded
Memory Allocator:
http://developer.apple.com/technotes/tn2004/tn2124.html
Niko
On Dec 8, 2005, at 2:46 PM, Lee Cullens wrote:
Thanks Niko - cool,
At least it confirms that I have been looking for the problem in
the right area. I'm going to have to learn a lot more about gdb,
though, before I can find what is causing the problem. This is
what gdb gave me:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0xfffeff20 in objc_msgSend_rtp ()
(gdb) bt
#0 0xfffeff20 in objc_msgSend_rtp ()
#1 0x928b7ea8 in NSPopAutoreleasePool ()
#2 0x00003ed4 in main (argc=1, argv=0xbffffb40) at TestMain.m:129
which in my main() source is:
line 39 // create base memory management pool
line 40 NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
...
line 128 // release base memory management pool
line 129 [pool release];
line 130 line 131 return 0;
and my Foundation tool ends otherwise normally :-(
which I believe means I have to figure out how I'm screwing up the
main() (base) pool. I'm going to start by commenting out sections
of main() until I see what area the problem arises from. My
instance methods autorelease newly created and initialized instance
objects into the current pool which is generally the local pool of
a function. The instance objects I don't want to lose I send a
retain message before releasing a local pool and returning from a
function.
In my trace I'm already showing retain counts to be sure they look
right - guess I have not done enough.
Anyway, if anyone has had any particular experiences with this
error situation that they think bears noting it might be helpful :-)
Thank you,
Lee C
PS: The main reason I'm working on this Foundation tool is to get
a good grasp of using autoreleasePool. I used to do all my own
memory management, but if I'm going to use NS objects I better get
used to it.
Niko Matsakis wrote:
Bus errors are usually caused my pointers that are not properly
aligned, or other accesses to invalid memory.
If you load this program into gdb and execute it, you will be able
to get a backtrace of where the bus error occurred. Do something
like:
gdb -args ./a.out arg1 arg2
(within gdb:)
run
(after crash:)
bt
Niko
On Dec 8, 2005, at 9:17 AM, Lee Cullens wrote:
I'm new to ObjC/Cocoa and have a dumb problem I can't seem to
find. I'm using Terminal gcc to compile and link a small
Foundation Tool I' m working on. I have not really got into
Xcode yet.
Anyway, the short of it is that at the end of my test output I
see the line "Bus error." I "assume" for the moment that it is
an indication of a memory problem in my code, but I'm having
problems tracking it down. I've read everything I could find
about memory management (NSAutoreleasePool) and think I
understand ownership, responsibilities, nested pools and the like.
My question is: What all (generally :-) might cause a Bus error
and is my concentration on a memory management issue a potential
candidate? If it is a memory management issue, what tools,
methods, whatever might help me find the problem. I'm old-school
(a retired SE dating back to the 60's) and have a trace option in
my code, but have not yet been able to find something that might
cause the issue. So I'm resorting to bothering you-all for
possible pointers :-)
Thank you,
Lee C
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden