printf() miracle cure?!

D

DrM3M0RY

Registered
I'm working on a C++ program using Project Builder, and I came across something really odd. When running the executable in Unix, I receive a bus error. After some intense sluthing, I discovered where the problem occurs: an if statement that only uses variables (ie if((x > y) || (x < y)){ ). So, naturally, I create a printf() statement just before this to display the variable— and the bus error is gone. This works for one of the two variables used in the if statement, but only with stdout. I tried ssprintf(), but that didn't work, but fprintf(stdout, ...) did. What does stdout have to do with these variables :confused: ?! Anyone care to explain?
 
I've never had this problem before. That said, I've not used Project Builder for years now. I'm guessing that this is a bug in the version of GCC that is shipped with 10.1 or 10.2.

You might want to try changing the build configuration from Debug to Release to see if that helps. It could be some optimization flag that is causing the problems. You won't know until you check it out, I suppose. The other alternative is to upgrade to 10.4 and get Xcode 2 with the latest GCC 4.

Alternatively, I guess you could install gcc 4 manually but how you'd integrate that with Project Builder is something I haven't a clue about.
 
I've experienced this before. Sometimes I'll put an NSLog in my code to debug a problem, and it'll be fixed... not really sure where the logic in that is.. probably something completely unrelated.
 
Not really noticed a problem like that, but are you really using: if((x > y) || (x < y)) {} ?

If you are, it could easily be a bug in GCC trying to optimize that into an x != y.
 
This could be a couple of things. It could be a compiler bug. In that case, I would compile to assembly and study that looking for the bug. Changing the level of optimization would be interesting.

The other problem it could be is a bug way off somewhere else that is trashing something that is causing the bug. Adding in a printf statement moves things around and changes the symptoms. One idea is to use gdb. Go ahead and let it die and then poke around with gdb to see the values of the registers, look at the stack, etc.
 
The only thing I would caution against is the fact that compiler bugs are really rare in the scheme of things. If adding a printf makes your program run then that tells me you are overwriting something on the stack by running past the end of an array or using an improper cast.

Dollars to donuts that is the problem.
 
A bus error is caused when the stack gets corrupted; this is not a problem with the compiler. There is some serious problem in the code that is overwriting your stack. You should check to ensure that you are using length limited string functions to prevent overwriting the end of your string, as this will corrupt your stack.
 
I agree that this is not likely a compiler bug. gcc is old and well established.

If you can use gdb, one way to maybe track this down is to first let the application crash (while running under gdb). Try and find something that is trashed -- the stack is likey. Maybe the TOC.

Then I think you can set a watch point in gdb and maybe catch the point in your code that is trashing things. This may be tricky depending upon what is getting corrupted. What you'd like to find is a place that is corrupted that rarely gets changed.

Of course, one very frustrating things is the program's behaviour can change while running under gdb.
 
You must log in or register to reply here.
Back
Top