• 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: Disappointed with XCode debugging (Solved)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Disappointed with XCode debugging (Solved)


  • Subject: Re: Disappointed with XCode debugging (Solved)
  • From: Ricky Sharp <email@hidden>
  • Date: Tue, 20 Apr 2004 17:50:17 -0500

On Apr 17, 2004, at 9:39 PM, Ricky Sharp wrote:

I must say that I'm very disappointed with XCode. While I did manage to migrate my CFM--based app from CodeWarrior and got it to compile and link, it does nothing but crash.

How embarrassing!

I've found the culprit in my code and it definitely was due to memory corruption during static initialize time.

Look at what I had:

In foo.h...

#define kNumberOfFlags	1024

class CFoo
{
    static UInt8  sFlags[ kNumberOfFlags ];

    static void Initialize( void );
};

In foo.cpp...

UInt8 CFoo::sFlags[ kNumberOfFlags ];

void CFoo::Initialize( void )
{
	::BlockZero( sFlags, sizeof( UInt16 ) * kNumberOfFlags );
                                 ^^^^^^
}

Ouch!

I just checked the sizeof( sFlags ) in CodeWarrior (with the CFM app) and it reported 1024 bytes. That BlockZero was definitely trashing 1024 bytes beyond that array. In the real class, there's a second static array declared just under the sFlags array. Just a guess, but perhaps the physical order of the static data in the header dictated the memory layout, and the BlockZero was doing something "harmless" by clearing the first 1024 bytes of that second array.

In fact, I just proved that by replacing the first BlockZero with a memset( sFlags, 0xCC, ...). The generated code was overwriting the first 1024 bytes of the next static array.

In XCode (with mach-o app) the sizeof( sFlags ) was also 1024, which I would expect. It was nice that the generated code was being more strict in that I was overstepping the array bounds!

While I definitely don't need to rely upon the actual storage layout of an object, I'm now curious if anyone's done analysis between CFM and mach-o apps in this regard.

___________________________________________________________
Ricky A. Sharp         mailto:email@hidden
Founder & President
Instant Interactive(tm)   http://www.instantinteractive.com
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.


References: 
 >Disappointed with XCode debugging (From: Ricky Sharp <email@hidden>)

  • Prev by Date: Re: xcode chokes on #include<somefile.lxx>
  • Next by Date: Breaking to debugger on exceptions
  • Previous by thread: Re: Disappointed with XCode debugging
  • Next by thread: FYI: Filing bugs now requires Sys Info report
  • Index(es):
    • Date
    • Thread