I am porting a big and complex c++ server from Solaris to Windows. I am facing lots of trouble due to uninitialized member variables. On Solaris they get set to 0 value by default hence things work fine. But, on windows those member variables get garbage values assigned creating mayhem in the system.
Code base is too huge to manually check each class. Are you aware of any tool or Visual Studio settings that would issue warning if the member variables are not initialized in the constructor?
Thanks in advance!
cppcheck does a very good job at finding uninitialized variables.
You can also use an external tool for such task, like PCLint.
You can enable the Code Analysis in Visual Studio (C++ Projects):
Project Propertys --> C/C++ --> Enable Code Analysis for C/C++ on build
Related
I've built a 64 bit version of the OpenH264 DLL in debug mode (with no compiler optimisations) and am calling it in C# (via Unity). I'm using Visual Studio 2017 to attach to the running Unity process and debug my dll.
I can place breakpoints and step through the code, however all values for the code seem to be random (or sometimes null).
For example this is where the debugger reports NULL as the value of a pointer but is stopped on the line after a failed NULL check.
Why is this happening and what can I do to get correct values when inspecting variables?
Maybe due to "At this time, Visual Studio Tools for Unity only supports managed DLLs. It does not support debugging of native code DLLs, such as those written in C++."
1 Please try to switch the Common Language Runtime Support under Configuration Properties :
2 Another potential reason is that the variable is not in the current context:
While debugging, Visual Studio will keep track of every variable in the current context
I would like to examine the contents of an environment variable while I am debugging a C++ program in visual studio. Have googled lots but have not found the procedure to do so... any advice on how I can do this? Thanks!
None of the suggested methods worked for me... I do not know why (though I'm sure I was just missing something simple). I wound up using Process Explorer to examine the environment for the process, gave me the info I required.
Adding a watch that calls the C getenv function (e.g. getenv("PATH")) seems to work.
Environment: I have a .NET 4.0 solution that references some Visual C++ projects. Visual Studio 2010.
If I build my solution and run the resulting .exe right from the bin directory, I can reproduce my bug. But if I run it hitting the "play" button in Visual Studio (or if I run the process and attach to it) I can step through the code, and everything works as normal.
For reference, the problem I'm getting is an Access Violation which is most definitely happening the C++ code.
But more broadly, I'm wondering what other reasons there might be that attaching a debugger to a process "fixes" the issue.
MS VS is working like a sandbox. When you are starting app in that sandbox, your program inherits all settings from solution properties (or just VS settings). Make sure, all your options provided for the environment are correct. If that wont solve the problem, please double check those settings and think what can prevent access violation and uncheck/check it.
If you are using external DLL, those from you system and those from IDE may have different version. They, of course, may work in both cases, but also may cause problem like access violation or subcribent out of range, depending what is changed inside those dlls.
If its Windows app, try enabling/disabling LargeAddressAware.
If you are compiling stuff for another machine with different OS, it may happen very often due to changes in memory handling by native OS. Memory can sometimes be multi-blocked, extremely fragmented or even multi-deviced, so compile your program only with compilation especially made for targeted OS/machine
debug mode uses assert() and other stuff directly linked to debugging. If something is wrong in debugging and not in release, it means that it is acceptable by machine but not by debugging insertions. In that case you are screwed but if its not appear to be problem in other debugger, well... problem solved, its debugger issue, espeially if release without debugging options is working.
most tiring method - try to pinpoint access violation address and see inside memory windows to what are you referring.
in other cases, supply us with snippet, so we can tell something more!
#Matt this cant be heap problem, it can happen but its extremely rare.
#Huytard its wont happen, without linked dll's program should't even start.
The correct and short answer. Run Windows Updates.
The correct and long answer.
It turns out my build machine hasn't been updated in a while and was using an outdated version of Visual C++ compiler. There was a bug in the compiler for .NET 4 where static constructors were not getting called first before any other types of constructors (only in Release Mode).
But here's the kicker!
If you run the process in the Visual Studio debugger OR you attach to a remote process. The static constructors DO get called first like they are supposed to! (Hence making the issue completely un-reproducible in a debugging environment -- Even in Release mode) I found the issue by placing message boxes all over the place to determine the code path.
http://connect.microsoft.com/VisualStudio/feedback/details/611716/c-cli-class-static-constructor-not-called-in-release-build
Running the green "play" button will use the IDE's environment
Executing from the directory will use the default environment
My guess is that there are probably some DLL's or dependencies that need to be added (directory paths) to your %PATH% environment variable.
Once you identify the dependencies and double check or something with dependency walker - you can set them in a batch script and then call your application.
For example:
#echo off
set PATH=%PATH%;C:\myLibs
call MyApp.exe
I compiled a program using freeglut, optix, cuda and other libraries (some of them dinamically loaded). It compiles and runs without problems in Visual Studio but it crashes if I execute it outside Visual Studio. Both release and debug versions work within VS, they both crash without any information on Windows 8 if I try to execute them directly.
I already included all the necessary DLLs, that didn't work.
What could be the problem?
Most such observations are usually coming from undefined behavior -- using uninitialized variable, dangling pointers/refs, overrunning buffer.
You may try to use Application Verifier, with some luck it might rearrange the used memory enough for you to trigger the problem under debug to help corner it.
Also, when it crashes you should get a prompt to launch VS and inspect the problem -- did it not indicate a hint? What was the immediate cause of the crash and what you had on the call stack there?
You can try comparing the environments between visual studio and the default environment.
Dependency walker should identify any missing DLLs.
Get WinDBG, then File > Open Executable and run the program under WinDBG. When it crashes, you will get some more information. My answer here describes an issue in .net, but the concept applies to native C++ as well.
Visual studio runs executables under "debug" mode, meaning a debugger is present.
What does this mean? If you check out the msvcrt implementation, if the runtime detects a debugger is present (IsDebuggerPresent), then heaps preform differently.
What does this mean? It means buffer sizes are "nudged" upwards, it means memory allocations are wiped clean by default (no need to memset), etc.
This can cause a variety of bugs to manifest, or some more subtle bugs to be hidden.
I have a problem with my C++ application. It was developed on a 32bit pc, on Microsoft Visual Studio 2008, and now I am trying to run it on a 64bit pc.
On my 32bit pc it works fine; on the 64bit pc, Visual Studio does not give any compilation problem, but then on execution gives wrong results.
And I have undestood why.
In the code, I define a variable, of tipe "dag", that is a structure for a direct acyclic graph. By debugging the software, I noticed that, although I declared it, later the software is not able to insert data in it, and the debugger says:
CXX0017: Error: symbol "dags" not found
Here's my code:
Dag<int64_t>* dags = new Dag<int64_t>();
dags = getDagsFromRequest2(request, dags);
The very strange thing is that, if I follow the flow inside getDagsFromRequest2() function, I can clearly see that dags variable is full of data: on "quickwatch", it shows 2342 nodes inside it. But when I come back from getDagsFromRequest2() function to this part of the code, debugger says "CXX0017: Error: symbol "dags" not found". How is it possible?
You can also see this screenshot from my Visual Studio debug set.
What could be the problem?
Thanks a lot
There are a few possibilities to consider:
Running in Release builds. Switch to a Debug build.
Using a Debug build that has optimizations enabled and/or debug information disabled. Disable the optimizations and enable the debug information (look in another project for the relevant settings).
A corrupt build of some sort. Clean and rebuild the entire solution.
Memory corruption which is preventing the debugger from displaying the variable. Ensure that no memory issues exist with a tool like Valgrind.
A VS bug. This report for VS2010 seems to suggest a known bug with similar characteristics for example. Ensure all patches and hotfixes for VS2008 are installed.
The variable dags is defined as your code compiles. The error you see is simply related to the debugger. I am guessing it is caused by running the application in Release mode which sometimes causes confusing and wrong watches values. Try changing the mode to debug(there is a drop down from which you can choose the build mode).
EDIT: as you say you are running in Debug mode, my next guess is that this behavior could be caused by stack corruption. Try using valgrind to detect if that is the case. It may take a while to start with it,but it is worth it and will detect if you have some memory corruption.