OK, this is the wierdest coding problem I have ever faced. X-Files alien-abduction type wierdness (well almost).
I've been scratching my head why my new file caching algorithm isn't behaving as expected with my test program. Then I discovered that it starts behaving as expected when I added a printf() in a called function. Ok, a bit wierd. *Then* I discover that it behaves as expected when that printf() is put inside an If statement THAT IS NEVER EXECUTED. In other words I have something like this:
if (a==b) { printf("This is never printed!\n"); }
EDIT: For clarity, I know that "a" never equals "b", so I can guarantee that printf() isn't executed... yet it still makes my code work! (I also added a \n to the string to avoid having a red-herring.)
So what the hell do I do now? Start sacrificing goats to the Mayan god?
P.S. This is actually c++ code compiled by g++. No extra command line parameters are used, so no optimisations are taking place.
Edited by ChrisH on 2014/3/25 9:27:26 Edited by ChrisH on 2014/3/25 9:31:39 Edited by ChrisH on 2014/3/25 9:32:14
Er... it would help if you told us what the actual problem is, preferably with some sample code, otherwise it's going to be impossible to deduce what is going on.
Without knowing what you're trying to do, I've seen that sort of behavior in timing sensitive bits of code before. The printf, or an if condition check, slowed things down just enough to work. Or in other cases took too long, and interfered with what we wanted. This was in DMA type stuff, when we were waiting for something from the controller. If we waited too long, then the buffer overflowed in the meantime and we lost data. If things didn't take long enough, then we tried to read a buffer that wasn't full yet, and we missed some data not there yet. So we had to figure out what the right thing was to wait on, and where we could and could not put printfs for debugging output.
What you describe is also often relevant of a bad stack shape. Especially if you are doing intensive use of printf family functions double, triple, and even quadruple check concordance of your format string and your arguments (count *and* type).
Of course René's suggestion is the first to check (i.e. flushing output either by explicit call to flush, either by adding '\n' at the end of your other printf calls.
@all OK, looks like I did a poor job of explaining my problem. I have edited my original post, but let me explain here too:
The printf() was making my code work... then I *intentionally* put it inside an If statement which I know always evaluates to false, so that I know the printf() will never be called... BUT IT STILL MAKES MY PROGRAM WORK!
i.e. A piece of code which is never called suddenly makes my program start working.
So either I am going completely mad, or GCC has some super weird bug... or there is some other possibility I overlooked.
@rwo The contents of the printf() was just an example. It's actual contents makes no difference, it can be "." or "munchkins will take over the world\n" .
@Chris The code is FAR to large to provide any sample. What I was hoping for was some debugging hints, or suggested work-arounds.
@billt Quote:
Without knowing what you're trying to do, I've seen that sort of behavior in timing sensitive bits of code before.
There is NO timing sensitive code (it's single-threaded & only makes a few DOS calls)... But even if it WERE timing sensitive, how does a printf() which is (intentionally) never executed caused a timing problem?!?
i.e. A piece of code which is never called suddenly makes my program start working.
So either I am going completely mad, or GCC has some super weird bug.
That's clear you are trashing your stack and/or your heap. Adding statements to your program change the shape of your program and it does not crash anymore where it used to (but it will a bit later...or sooner depending where you added your statement). Good luck debugging your code that's one of the most difficult case to chase. Starting with my suggestion is then a good start (or running a code analysis program, like lint or similar).
My programs never crashes (whether working or not). When not working correctly, the algorithm just produces the wrong behaviour (which gives the appearance of a calculation producing the wrong result, leading to the wrong behaviour every time).
Also, the code to make my program start working is effectively this: if(false) { printf("I am intentionally never executed\n"); }
So could it still be stack corruption? Seems a bit of a stretch to me (although it's the first vaguely-plausible idea I've heard, which is much better than sacrificing a goat).
Since I'm doing lots of memory copying, I'll try disabling them & see what happens. Maybe I am trashing memory & this somehow leads to non-crashing behaviour.
Another simple thing to check is to increase the stack size by 10 or 100 and see if it makes any difference.
The printf() call will almost certainly use registers and/or stack space while making up the arguments for the call. That use of local variable space may be the real cause of the change in behaviour. That's why I suggest increasing the stack allocation, simply by using the "stack 262144" command or similar from the Shell, before running the program.
Wouldn't a program without enough stack crash? Chris said his program does not crash, but just produce unexpected results while adding a never executed statement (i.e. if(false) printf();) it starts producing good results.
P.S. This is actually c++ code compiled by g++. No extra command line parameters are used, so no optimisations are taking place.
Taking you literaly on the no extra paramteters, the first thing to do then is switch on -Wall and -Werror then fix the warnings.
If you do have then warnings switched on the Ironically it wont; warn abiout unitiliased varaiables until you turn the optimisation on (needs the ectra code analysis performed to trace the code flow). So add -02 to get warnings on unitilised varaibles, which must be the most likely cause as far as I can see.
[edit] BTW when you added printf did you also add #include <stdio.h>? if so is there any other code that might have needed that header? That may be working correctly now that it has the correct function prototype etc? [/edit]
Wouldn't a program without enough stack crash? Chris said his program does not crash, but just produce unexpected results while adding a never executed statement (i.e. if(false) printf();) it starts producing good results.
Probably, but what's a crash? Code not executing as expected. Bumping the stack eliminates the stack from the equation and is always worth doing as it takes so little time.
[edit] BTW when you added printf did you also add #include <stdio.h>? if so is there any other code that might have needed that header? That may be working correctly now that it has the correct function prototype etc? [/edit]
That one is also a good one: not having correct function prototype or not including the header defining them before using functions may lead to such problem especially if your expected result is the function return value (remember that when GCC find a function without having its prototype first it assumes return value is int, if in the end that is not the case and the return value is bigger or smaller than an int then you might start having problems...)
That one is also a good one: not having correct function prototype or not including the header defining them before using functions may lead to such problem especially if your expected result is the function return value (remember that when GCC find a function without having its prototype first it assumes return value is int, if in the end that is not the case and the return value is bigger or smaller than an int then you might start having problems...)
I've had something similar when I've completely forgotten to "return val;" at the end of a function. The result is the function ends up returning whatever the last variable used was (or something like that anyway). This caught me out because it worked without optimisations, but when optimisations were switched on it stopped working. Of course, enabling warnings picked that up.
There is NO timing sensitive code (it's single-threaded & only makes a few DOS calls)... But even if it WERE timing sensitive, how does a printf() which is (intentionally) never executed caused a timing problem?!?
You mentioned there are no optimizations on.
You've added an if block. That's new, so let's for the moment set the printf aside, and focus on the if itself. The if condition check may be accomplishing the same mysterious magic that the printf did before you wrapped it in an always-false if block.
If you remove both the new aways-false ifblock and hte printf inside, does your code continue to work, or does it revert to failure as it did before adding printf and if checks? If it goes back to failure, then that if is causing something different to happen.
What could an if block cause to happen, particularly an always-false one that will never run its contents? Well, the a==b check is done. If nothing else, that takes time, moved the PC, maybe did a memory access and changed the pipeline state compared to the program without this a==b check.
If you can replace the if and its printf contents with an empty while loop of an iteration or two, and things will still work, but the program fails without anything in that location, then somehow it's timing related.
@abalaban It might be a stack problem (or it might not!).... More wierdness:
Getting rid of all uses of MemCopy() (which PortablE implements using memmove()) makes no difference, sadly.
The never-called-procedure doesn't have to be printf(), as a user-defined one will do... as long as it is called with similar parameters. Due to a quirk of PortablE, it's calls to printf() have multiple 0 parameters, so something like dummy(NULL,0,0,0,0,0,0,0,0) will work just as well, but dummy(NULL) will not.
EDIT: dumy(-1,-1,-1,-1,-1,-1,-1,-1,-1) works just as well.
Putting the never-called printf()/etc in a parent (caller) or child (callee) procedure doesn't work, it has to be this particular procedure (even though the bug most likely occurs in one of the child (callee) procedures).
Putting the never-called printf()/etc at the end of the procedure works just as well as at the beginning!.... (EDIT) Even though the misbehaving code must be executed before it!
Adding an local variable array (of a size similar to the parameters passed to the never-called printf()) to the relevant procedure (instead of the mysterious printf()) doesn't help, even if I initialise it to zero.
if (false) printf(); doesn't work, it has to be something like if (this==NULL) printf(); I guess GCC must be doing some trivial optimisations even with -O0.
Edited by ChrisH on 2014/3/25 19:48:37 Edited by ChrisH on 2014/3/25 19:49:15 Edited by ChrisH on 2014/3/25 19:50:53 Edited by ChrisH on 2014/3/25 19:57:34
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
