• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: 0x3ff00000 is what, exactly?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 0x3ff00000 is what, exactly?


  • Subject: Re: 0x3ff00000 is what, exactly?
  • From: Glen Simmons <email@hidden>
  • Date: Thu, 20 Nov 2003 15:57:30 -0600

On Nov 20, 2003, at 2:46 PM, David W. Halliday wrote:

email@hidden wrote:

So, I have this program that creates about 1000 instances of one class. Every now and then it just crashes mysteriously, and debugging shows it to be attempting to send a message to a non-existent object (EXC_BAD_ACCESS).

However, this object exists, as given by the same behavior if I include an
if (obj == nil) return;
before calling the particular method that crashes (always the same one, a method that accesses the NSString that represents the path).

However, while it is not always the same object it crashes on (these objects represent paths, among other things) the object is always at address 0x3ff00000. Does this address have some significance? The debugger shows all the instance vars to be 'invalid', as though there isn't really an object there, or something.

Any thoughts? Is this some kind of out-of-memory error? Is there a limit to the number of objects you can instantiate? The number of NSStrings?

I'll try to make a simple test program to isolate the problem, if I can.

Thanks,
J.D.

I have no /real/ idea why the address is "always" the same, I'm certain that just because the pointer to the object is not nil (your "obj == nil" test) guarantees nothing about the validity of an object at the address in question. The trouble is that if the object is no longer valid, then you cannot tell just by looking at the value of the pointer that used to point to the object in question (other than to devise a test on whether there is an actual, valid object there).
I recommend that you check your retain/release/auto-release chain. All it takes, to have a non-nil object pointer to no longer /be/ a pointer to a valid object, is to have the object in question freed before your call.

The NSZombie stuff is of great help with this. See NSDebug.h.

HTH,
Glen
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >0x3ff00000 is what, exactly? (From: email@hidden)
 >Re: 0x3ff00000 is what, exactly? (From: "David W. Halliday" <email@hidden>)

  • Prev by Date: Limit NSTextField Size of Input
  • Next by Date: Re: Mailing list: General options
  • Previous by thread: Re: 0x3ff00000 is what, exactly?
  • Next by thread: Re: 0x3ff00000 is what, exactly?
  • Index(es):
    • Date
    • Thread