On Feb 10, 2007, at 1:12 PM, Theodore H. Smith wrote: Xcode was using a different kind of malloc that would fill my data with certain values that somehow allowed my code to work properly.
Could you elaborate? The malloc that's used is generally determined at link time, and you said the problem was with the same binary executed different ways.
There is a consideration that Xcode has modes where you can inject an override to libmalloc for debugging purposes, but a) that usually causes code that "works" in Terminal to misbehave in Xcode, not the other way around; and b) takes some doing and is not something that you could set up accidentally. Running my app from the terminal used a different version of malloc that used some garbage values.
Again, if you can explain how you determined it's a different version, that might illuminate an actual bug in Xcode or Mac OS X. Obviously, this is an error in my app. A classic memory management error :( Shame, I really hate those things. But they are unavoidable when you are writing high performance stuff, because in these cases you can't rely on vectors or other easy stuff to "do the right thing", speedwise.
Anyhow, I did solve this problem. The answer to my question was that Xcode was linking to a different version of malloc.
No bug in Xcode, just a bug in my code that the terminal (strangely) was better at uncovering.
Are you sure it wasn't just a bug in your code that behaved differently under different circumstances, such as when your code is running with Terminal as the parent process vs. Xcode or gdb? Or with different latent memory values that just happened to not cause your program to error out with one set of random values but did with another?
So while it's clear that it was a bug in your program attempting to use allocated memory before initializing it, I'm still interested in following up on your assertion that the values were different because "a different kind of malloc" was used. If there’s some way that Xcode is executing your code in not-real-life circumstances, we want to know about that.
Chris |