Recently i have been experiencing more and more corrupt builds.
For instance when i access
npc[4]
it accesses
npc[3].
Or instead of
details->Hp
it returns
details->Energy.
Problem magically fixes itself when i rebuild. (after i spent hours trying to find the non-existing bug of course)
This is getting more frequent while my project gets bigger and bigger.
Why does something like this occurs?
How can i avoid it?
I hope i made myself clear.
thank you.
thanks for the comments. i have found the problem.
precompiled headers. they get corrupted after a while and cause unintended behaviors.
there doesn't seem to me solution at the moment since I'm forced to use pchs.
Related
I am very new to coding C++ and to using the Netbeans IDE. Worse yet, I'm on a Mac (but I can't imagine that's the source of the issue this time).
The IDE is giving me countless nonsense "hints" as in red exclamation mark symbols, most of which say "Unexpected token" for things like ';' at the end of a statement or '=' in a statement. These are of course ridiculous because, as I understand c++ so far, they are necessary for even the most basic statements!
screenshot here
What could possibly be causing this and how do I get rid of the hints or, preferably, fix something if there is an error somewhere?
Delete your Netbeans cache. In my case the problem when away when I did this. I think I initially ended up in this state because my C++ project was under a Java project. After separating the two the error was still present even with a clean/build. Deleting the Netbeans cache got rid of the problem. Even if your situation is different you should try this. Clearing the Netbeans cache once in a while fixes a lot of issues.
Tyler,
I'm going to go out on a limb and guess that you've got your Net beans ide setup to use another language other than C++. Remake the project and make sure your using c++
I had the same issue.
The issue was, I wrote C++14 code, in the C++ project.
To resolve this:
- Create a C++14 project (Select from the drop down, while creating the project)
- Add existing C++ files to it
Hope that helps.
I started working on the GUI aspect of a C++ application in Visual Studio 2015, after including <windows.h> I got extremely cryptic errors with other files having syntax problems. I discovered that including that header file was the source of the issues.
I looked around online and found out about NOMINMAX but defining that didn't resolve the problem. I was using numeric_limits<int>::min()/max(), and one for ::infinity() with floats, so NOMINMAX will solve that minor issue, but didn't solve the major issue of these syntax errors occurring as the min/max problem compiler errors were pretty specific.
Moving the header to the very bottom seems to have solved it temporarily, however I am not happy with this at all because it means I have a potential timebomb in my code and I'm not sure where. Right now its 5k LOC but I'd rather deal with it know than get to 50k and run into this issue in a way that forces me to deal with it.
What techniques do I have of finding out where the error is occurring? Can I possibly dump the files after pre-processing? Going through and commenting everything out would be particularly painful... but I don't know if I have a choice. I have a general idea of the location but its occurring sadly on very prominent set of includes, so the amount of commenting needed to attempt to isolate this isn't too pleasant.
Is there a tool or some method to aid me in this problem? Or am I stuck having to do it the long and dirty way?
NOTE: I have also tried WIN32_LEAN_AND_MEAN, NOMINMAX, and VC_EXTRALEAN in attempts to solve this but that does not work.
EDIT: I have tried commenting/trying to find out what is causing it from the indicated lines but there are so many files/LOC that the resulting mess (due to this unfortunately occurring on frequently used files) means that the amount of work in tracking this down quickly became a nightmare, and thus I'm posting here looking for any heuristics on how I could identify this problem. It also compiles fine and uses all the functions where these syntax errors are occurring when I don't include the header file, so the code itself cannot be broken since the applications literally uses them and runs great.
My solution came from deciding to manually include the windows.h include files one at a time to see what was causing it. This eventually led me to discovering wingdi.h was causing the issues, and #define NOGDI solved the problem. Further googling around yielded that a chunk of the names in there can collide with class names, which I confirmed at least one of did.
I have a Visual Studio 2008 solution which consists of some projects and uses dll's with theirs' headers. In the debug version it (the solution) works really well. And in release version it compiles successfully, but on executing some functions which are defined in a dll file it fails.
As I said, the solution works fine in debug mode, and options set properly. Tried turning off
optimization, turned on debugging information, it didn't help. What can be the cause of the problem?
I have seen this happen many times before. In almost every single case the problem was found to be an out-of-bounds error when writing to an array or other data structure. In other cases, an uninitialized variable was being used.
You have a bug in your code. That is certain. When you build under Debug settings, the compiler does a whole lot of stuff for you that masks certain types of problems. The compiler will write code that zero-initializes some stuff, masking uninitialized variable problems.
First thing I wold try is cranking up the warning levels to their highest settings. You should be doing this all the time anyways. This will very often reveal the problem. Just be sure to fix the problems the compiler tells you about. Don't mask them with #pragmas or chintzy casts. Next step through your code to isolate the problem. This can be difficult and time consuming, but there's a silver lining. Whatever the problem is, the likelyhood of you repeating that mistake is inversely proportional to how long and how hard it is to identify and fix the bug. :)
Alright, I need a sanity check.
I was working on my project by starting to add a new class yesterday and decided to compile my progress so far. Upon executing a release build of the application I immediately noticed a bug. (Which in this case is an asteroid field not showing up for my game) This immediately confused me since I hadn't touched any code that could of created this bug. And everything else is rendered fine as usual.
Fast forward a day later and I think I've narrowed down the cause however it doesn't make any sense to me at all.
It only happens intermittently with release builds. (About 1 in 5 executions) But I can prevent it happening altogether by simply not including my new class in the project. Even though the class isn't being used or included by anything else in the project yet. I even went a step further and found just commenting out the class definitions and leaving the header is fine but the second I uncomment them it comes back. And for further testing I included it in an older build with the same results.
Would unused code affect the compilation of a release build? Does this sound like a Visual Studio bug? Or does it not make any sense at all? (In other words, did I just find a really convincing red herring?) Is there anything I can do to help figure out the source of this bug?
Would unused code affect the compilation of a release build?
Yes. As this SO answer explains, Visual C++ keeps unused functions that aren't marked as inline.
Does this sound like a Visual Studio bug?
It's unlikely, as I'll explain in answer to your next question. Eric Lippert explains that, because the compiler is used so often that the easy and commonly seen bugs have already been found and fixed, it is far more likely that the bug is in your code than that the bug is in the C++ compiler.
Did I just find a really convincing red herring?
Yes, I believe you did. Without seeing the code for drawing the asteroid field, I can't be sure, but it's likely that you are dereferencing a bad pointer somewhere in there. Now it starts to matter which data the pointer points to.
When the unused class is included in the compiled assembly, the memory devoted to your code is larger, which means that your heap has to start higher in memory, and a bunch of things move to higher addresses. This means that a bad pointer can point at different data depending on whether the unused class is compiled into the executable or not. When you dereference that pointer, then, you get different results. That's why removing the code appears to "fix" the bug - whenever you take out the unused class, the bad pointer points at the data you want, rather than at other data. As #awoodland rightly points out in the comments, you're really unlucky without the unused class and lucky with it, because you fail to find a bug that could manifest itself in all kinds of weird ways once you start distributing the code to your friends (or customers, if this is a commercial product). These kinds of "bad pointer that happens to work" bugs can easily cause your code to appear to work correctly on some machines and fail dramatically on other machines, which is very difficult to debug. Better that you found the bug now than later.
I need to build some old codes I got on my office computer, which has gcc 4.4.5 installed. I edited the code (deleting .h or adding things like <cstring>) in order to bring them up to date so they can be compiled by gcc 4.4.5. However, after a seemingly successful compile the binary file gives out buffer overflow every time I run it. But the code runs with no error on my computer at home (gcc 4.1.2). So is it possible the change I made caused this error? I am not sure since I am not really a programmer.
Far more likely is that the original code was buggy in some way (undefined behaviour, buffer overflows and so on) but the old compiler created (or the old library contained) code that was more tolerant of these issues (a).
I'm afraid you will probably have to go and fix (or get someone to fix) the root cause of the problem. My question to you would be: "if you don't consider yourself a programmer, why are you editing the code and rebuilding it?".
My mother's not a coder either but she doesn't go around tinkering in the Linux kernel :-)
(a) Sometimes undefined behaviour actually works! That's actually its most annoying aspect. Far better that it would fail all the time so that we'd fix more problems before unleashing them on our poor customers. But, even when it works, that doesn't make it a good idea.