I am in big big trouble. Please help.
I have created a game for my client.
It works fine when I run it from the Visual Studio 2008( in both release and debug configuration).
But when I run its stand alone exe (or making setup project) it does not work perfectly fine.
It works but it does not work completely fine,and the problem is consistent(It shows the same problem every time, when I compile and run stand alone exe).
I had this problem in the past too but luckily I solved it.The way that problem was solved is very unusual:-
Every thing was working perfectly fine and then I made some modifications in the code.The application started showing the same unusual behavior as described above.Then i started rolling back the modifications in the code one by one.
The game started working perfectly fine when i removed a particular variable from a class and it uses.Then I checked all the C++ rules and every thing but found no issue in my implementation.Even every thing was working fine when i run from the Visual Studio.
But I needed that variable and its uses in the game for some functionality of the game.So, that time I declared the variable in PUBLIC (previously it was a protected variable) and every thing worked perfectly fine.
I am very surprised to see this unusual behavior, whenever i declare the variable as PROTECTED there is problem but if I copy and paste in Public the problem is solved.(The variable is only being used in the Class where it is declared so there should not be any problem).
Please Help me I am again getting this unusual problem and not getting any solution this time.
Please tell me what may cause this problem.
Thanks
Tarun
If it happens outside the debugger, but not inside the debugger, you may be able to reproduce it using the _NO_DEBUG_HEAP environment variable, as described here (amongst other places): Link
Setting this variable should make the program running under the debugger behave more like the program running outside the debugger.
You can set environment variables in Visual Studio, so they affect only the debugged process: How do I set specific environment variables when debugging in Visual Studio?
Changing the visibility of member variables can potentially change the layout of the class, since C++ only defines an ordering within visibility sections, not between them. Perhaps your change is breaking some code that isn't recompiled by your project.
I solved this problem. It was really very very hard to find the solution. I am writing here how to track this kind of bugs.
Some steps you should try first:-
1) Dont ignore compiler warnings. Remove all types of warnings.
2) Program to write the states of the variable in a file in near the critical portion of your program where you are in doubt that is causing error.
Write the states on each step.
Examin the Variable, you may find some un initialize variables or improper type cast or comarison.
Conclusion:
1) Avoid any coparison (equal to comparison)with floating point values.
2) If you are making time based comparison, make sure you comapre that care fully.
3) Do not this Microsoft People are god.
Related
I am facing a rather peculiar issue: I have a Qt C++ application that used to work fine. Now, suddenly I cannot start it anymore. No error is thrown, no nothing.
Some more information:
Last line of output when application is started in debug mode with Visual Studio 2012:
The program '[4456] App.exe' has exited with code -1 (0xffffffff).
Actual application code (= first line in main()) is never called or at least no breakpoints are triggered, so debugging is not possible.
The executable process for a few seconds appears in the process list and then disappears again.
Win 7 x64 with latest Windows updates.
The issues simultaneously appeared on two separate machines.
Application was originally built with Qt 5.2.1. Today I test-wise switched to Qt 5.4.1. But as expected no change.
No changes to source code were made. The issue also applies to existing builds of the application.
Running DependencyWalker did not yield anything of interest from my point of view.
I am flat out of ideas. Any pointers on what to try or look at? How can an executable suddenly stop working at all with no error?
I eventually found the reason for this behavior...sort of. The coding (e. g. my singletons) were never the problem (as I expected since the code always worked). Instead an external library (SAP RFC SDK) caused the troubles.
This library depends on the ICU Unicode libraries and apparently specific versions at that. Since I wasn't aware of that fact, I only had the ICU libraries that my currently used Qt version needs in my application directory. The ICU libraries for the SAP RFC SDK must have been loaded from a standard windows path so far.
In the end some software changes (Windows updates, manual application uninstalls, etc.) must have removed those libraries which resulted in that described silent fail. Simply copying the required ICU library version DLLs into my application folder, solved the issue.
The only thing I am not quite sure about, is why this was not visible when tracing the loaded DLLs via DependencyWalker.
"Actual application code (= first line in main()) is never called. So debugging is not possible."
You probably have some static storage initialization failing, that's applied before main() is called.
Do you use any interdependent singletons in your code? Consolidate them to a single singleton if so (remember, there shouldn't be more than one singleton).
Also note, debugging still is possible well for such situation, the trap is ,- for such case as described in my answer -, main()'s bodies' first line is set as the first break point as default, when you start up your program in the debugger.
Nothing hinders you to set breakpoints, that are hit before starting up the code reaches main() actually.
As for your clarification from comments:
"I do use a few singletons ..."
As mentioned above, if you are really sure you need to use a singleton, use actually a single one.
Otherwise you may end up, struggling with undefined order of initialization of static storage.
Anyway, it doesn't matter that much if static storage data depends on each other, provide a single access point to it throughout your code, to avoid cluttering it with heavy coupling to a variety of instances.
Coupling with a single instance, makes it easier to refactor the code to go with an interface, if it turns out singleton wasn't one.
I have some troubles with Embarcadero C++ Builder XE3. When I run my program, I have an access violation BEFORE the first instruction in the main...So I can't debug, it's very weird.
I used to have this problem a couple of weeks ago : I was forced to full rebuild the entire projet (even if only a comma was missing...) and the violation didn't occurs anymore. I solved it by ckecking the option "Disable incremental link".
I was very happy, but today, the problem is back, and whatever I do, my application crash before enterring in the main ...
Does anyone have an idea ? It's a big project, so I can't really post an exemple because I don't really know what to show...
Thanks a lot
Probably you have a bug in a constructor of a static global object. These constructors are all executed before getting into main(), so this can happen without being a runtime environment or a compiler bug.
As you told, debugging these is difficult as you probably don't know which class is failing, and probably you don't have exception info also.
As you say it's a large project, perhaps you have to resign to use large project toolkits/methodologies to deal with these problems, like unit testing and lean methodologies (like scrum or the like).
With the information you post I think this is the most can be said.
as the title mentions, I have a problem where one executable of a big project that gives a segmentation fault when it runs but is compiled normally and not with debug.
We are working on linux SUSE servers and code is mostly C++. Through bt in gdb, I have been able to see where exactly the problem occurs, which brings me to the question. The file is an auto-generated one which has not been changed for years. The difference now is that we have updated a third party component, gSOAP. Before updating the third party version it worked normally on both debug and not.
With debug flags, the problem disappears magically (for newbies like me).
I am sorry but its not possible to include a lot of code, only the line that is:
/*------------------------------------------------------------.
| yynewstate -- Push a new state, which is found in yystate. |
`------------------------------------------------------------*/
yynewstate:
/* In all cases, when you get here, the value and location stacks
have just been pushed. So pushing a state here evens the stacks. */
yyssp++;
yysetstate:
*yyssp = yystate; <------------------ THIS LINE
So, any help would appreciated. I actually dont understand why this problem rises and what steps I should take to solve it.
EDIT, I dont expect you to solve this particular case for me, as in more to help me understand why in programming this could occur, my case in this code is just an example.
First, please realize that you're using C++, not Java or any other language where the running of your program is always predictable, even runtime issues are predictable.
In C++, things are not predictable as in those languages. Just because your original program hasn't changed for years does not mean the program was error-free. That's how C++ works -- you think you have an error-free program, and it is not really error-free.
From your code, the exception is because yyssp is pointing to something it shouldn't be pointing to, and dereferencing this pointer causes the exception. That is the only thing that could be concluded from the code you posted. Why the pointer is pointing to where it is? We don't know, that is what you need to discover by debugging.
As to why things run differently in debug and release -- again, a bug like this allows a program to run in an unpredictable way. Add or remove code, run it on another machine, run it with differing compiler options, maybe even run it next week, and it might behave differently.
One thing you should not do -- if you make a totally irrelevant code change and magically your program works, do not claim the problem is fixed or resolved. No -- the problem is not fixed -- you've either masked it, or the bug is moved to another part of your code, hidden from you. Every fix that entails things like this must be reasoned as to why the fix addresses the problem.
Too many times, a naive programmer thinks that moving things around, adding or removing lines, and bingo, things work, that becomes the fix. Don't fall into that trap.
someone in my team found a temporary solution for this,
it was the optimization flags that this library is build with.
The default for our build was -O2 while on debug this changes.
Building the library with -O0 (changing the makefile) provides a temporary solution.
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.
This is a twisted problem. When I run my program using F5 in Visual Studio, everything works fine. If I start it without the debugger, or from outside VS, a few nasty bugs which I can't locate occur.
I suspect this is caused by the debugger randomizing all uninitialized variables, wheras "outside", they are set to 0. I must be using a variable without initing it somewhere...
Are there other possible explanations?
What should I do to find the bug - I can't use a debugger for it can I
How come the debugger in VS doesn't detect the use of an unitialized variable, if that's the case
As Hans Passant says, you have it the wrong way round. In Debug, memory is initialised, but in release it could be anything.
In general, if you have something going wrong in release that doesn't happen in debug then it could be down to a few things:
Relying on uninitialised variables as you said.
Optimisations changing the semantics of your code. This will only happen if you write code that is relying on ill-defined behaviour. For example, assuming that function arguments are evaluated in a specific order, or relying on signed integer overflow, or any number of things.
It's a timing issue that shows up more often in release builds due to the better performance. These most often occur in multithreaded applications.
You use different libraries in debug and release and rely on the different behaviour between them.
You can use the debugger to attach to a running program. I think it's in the 'Debug' menu in VS and is called 'Attach to process...'. Make sure that you generate debug symbols for release builds so that you get a usable call stack.
I had a similar problem recently except it was even weirder. The code worked fine when I ran release in visual studio, but when I ran the program outside visual studio (just clicked the .exe) it would do this very big bug.
Turned out it was because of:
angle = MathHelper.ToRadians(angle);
When ever angle was 0 it would fail and produce some weird results.
I fixed it by simply changing it to:
angle = MathHelper.ToRadians(angle+.01f);
Very very annoying problem for something so small. Hopefully this helps others find similar errors.