I recently wrote an implementation of the Canonical Huffman compression algorithm. I have a 500kb test file that can be compressed to about 250kb when running the debug and release builds from within Visual Studio 2008. However when I run the release build straight from the executeable the test file only compresses to about 330kb.
I am assuming that something is going wrong when the file is written using fwrite(). I have tested the program and confirmed that uncompressing the files always produces the correct uncompressed file.
Does anyone know why this could possibly be? How could the same executeable file be producing different sized outputs based on where it is launched from?
Sounds like an uninitialized value somewhere. See also:
Program crashes when run outside IDE
Running in IDE will initialize values to global defaults, running outside IDE doesn't, so any uninit'd variables will have different values.
Check out the the /RTCu compiler option to help detect use of uninitialized variables.
Try running it through App Verifier and see what it finds.
Related
I am working on a project with multiple compiled .exe files. They are mostly compiled in C++, but we also have JavaScript, XML, XSD, and XSL files. Debugging JavaScript is fairly straight forward since I can easily open the debugger tool on the browser. However, I am unsure how to debug the .exe files compiled in C++.
Since I am on a windows operating system, is there a way to use PowerShell (or Command Prompt) to debug the files? I've compiled the files in debug mode in Visual Studio (I'm assuming that is required). This is not a project that can be debugged in Visual Studio.
An example on debugging a simple program such as "Hello World" would be greatly appreciated.
Not an expert on .exe files, so there could be something I'm missing, but generally speaking if you're compiling C++, they're being compiled to machine code - just a step above binary. You won't be able to see the functions, variables, classes, etc. because it's all basically binary now. Compilation is an irreversible process - you can't get the original C++ code back.
JavaScript that's shipped to the browser is different in that browsers expect actual JavaScript code, rather than something compiled (though you can still compile JavaScript for an operating system with something like Node.JS).
If you're trying to change those executables, you'll need the original source code.
No, PowerShell can't be used to debug binary files.
It can only debug PowerShell scripts.
If you compile your applications to produce outputs that can be used for debugging, then it's another matter.
If I have a series of C/C++ programs that I need to build using Make , would it mess up the code run if I made changes to the code and recompiled while the program is executing an executable? Or is all the information preloaded in the executable before runtime?
Thanks.
This depends entirely on whatever operating system you're using.
Linux is perfectly happy continuing to execute a program whose binary has been removed, and replaced with a new binary.
It is my understanding that Microsoft Windows is, on the other hand, rather grumpy in the same situation, and won't be happy if something like this is attempted.
If I am understanding correctly, you can edit the code while you run the program and the program will not change while you run it.
I am very new to VC++ and I am running the program on VC++ for the first time.
I strictly followed the instructions given in Microsoft Programming Visual C++ book and created one project as instructions given.
About the ex03a.exe:
I saw in the path "...\Ex03a\Debug\" and in that no file exists such as ex03a.exe.
I tested my vc++ by executing a simple 'Test.cpp' file. I was able to run the simple c++ program and I got the output. And Test.exe is there in '\Test\Debug\Test.exe'
My Question:
How could I get rid off the error.
Almost always when VS says it isn't able to open a file, it's about opening it for writing.
And almost always this doesn't work because the file is locked.
And almost always this is because the file is an executable that is currently running :-)
This is a specialty of Windows - an exe is not simply loaded, it's locked for all of it's run time. This is probably due to the fact that exe files (actually called portable executables, for whatever reason) contain not only code, but usually also an arbitrary number of resources (like images, etc.), and changing the file on the fly would make the aplication crash hard when it attempts to read one of those resources at run time.
Therefore, I suggest looking for a way to exit / close / terminate the application, so it isn't running any longer, so the file is not locked anymore, so in this case the linker can do its work.
The error message, btw., isn't that intuitive from my point of view - this problem being SO standard, it could at least attempt to tell you anything about this possible source of the problem - afaik, this hasn't been improved until now, probably because most developers have seen this before, found out why it happened, and therefore do not have any more problems with it.
I see that in that screenshot, that you are running multiple versions of VC6.
Now You get that error if you run the newly compiled exe of that program without shutting down the previous compiled exe.
VC tries to overrwrite the exe that is currenty running but encounters that exact error.
Always close the program when you are done.
I have a program that runs fantastically when run from inside Visual Studio 2010 Express but when built and taken out, it has problems. I have set up the external test environment the same as when it is run from within Visual Studio so that shouldn't be the problem. I want to attach it to the .exe to see where the crash is but I don't have the non-Express versions.
Any suggestions? Why would a program crash outside of the the VSC++ 2010 Express environment but run perfectly inside.
I would post code but it's a huge project, not a line that would cause an error.
Thank you so much for your time.
It's very difficult to know for certain without knowing what the crash is, but a couple of common issues that may cause this:
Environment variables not the same. Perhaps you are relying on something in vcvars32.bat in your test environment.
The PATH environment variable is not the same and your picking up some bad or incompatible DLL.
Your code is somehow dependant on the current working directory being the one when run from Visual Studio.
Wikipedia to the rescue?
Time can also be a factor in heisenbugs. Executing a program under control of a debugger can change the execution timing of the program as compared to normal execution. Time-sensitive bugs such as race conditions may not reproduce when the program is slowed down by single-stepping source lines in the debugger. This is particularly true when the behavior involves interaction with an entity not under the control of a debugger, such as when debugging network packet processing between two machines and only one is under debugger control.
Also, note that User32.dll slightly changes its behavior when under a debugger, in order to make debugging easier for you. That shouldn't change anything, though.
You could debug this using the freely available Debugger Tools for Windows. There's plenty of documentation and quick start guides available, especially the chm included in the install. In your case, you may want to try the following:
Make sure you have the PDBs for your app available somewhere on a share.
Attach to the running instance of the app: windbg -p <PID>. Note that you can also start the program under the context of the debugger by doing windbg -g foo.exe.
Repro the crash.
Change the symbol path to your symbols and the Microsoft public symbol server to get proper symbols for components: .sympath x:\YourPathToPDBs; SRV*x:\symbols*http://msdl.microsoft.com/download/symbols
Tell the debugger to reload symbols using your path: .reload
Get a callstack by hitting k in the debugger.
That's the barebones you need to figure out where it's crashing. You can then go deeper and try to analyze exactly why it's crashing by looking at the debugger chm or other resources on MSDN or Tess's blog. One useful command is dv to dump local variables for a particular frame. If the callstack doesn't give line numbers, type .lines and then hit k or kb.
You could surround all code in your Main function with a try catch block. When you catch an excepcion, write to a log file the stack trace.
Then run your exe and check the log file to know where your program is crashing.
PS: Don't forget to place the *.pdb file together with the exe file, otherwise you won't be able to get the stacktrace information.
I realise this question is a couple of years old, but I have been experiencing the same thing and came upon a possible culprit (the actual culprit in my case), which may help others who have this issue.
One important difference when running an application within Visual Studio and running it outside is the Current Working Directory ("CWD").
A typical directory structure for a Visual C++ Solution/Project is along these lines:
Solution <- the location of your solution file
Debug <- where the Debug executables end up
Release <- where the Release executables end up
Project <- the location of your project file
Debug <- where Debug intermediate files end up
Release <- where Release intermediate files end up
When you execute the application from within Studio, either with "Start Debugging" or "Start Without Debugging", the default CWD is the Project directory, so in this case Solution\Project.
However, when you execute outside by simply double-clicking the application, the CWD is the application directory (Solution\Debug for example).
If you are attempting to open a file from the current directory (which is what happens when you do std::ifstream ifstr("myfile.txt")), whether it succeeds depends on where you were when you started the application.
I am using boost serialization with xml files with a C++ program.
When I test my program in debug mode, it is working fine.
Then I try with the exact same file in release mode, but my program fails when loading the files. I even tried to generate the xml files with my program in release mode, load them back, and it crashes as well.
The call stack shows this:
packs_ui_main.exe!boost::archive::basic_xml_grammar<char>::parse_start_tag(std::basic_istream<char,std::char_traits<char> > & is={...}) Line 219 C++
The actual bug is further but I have no debug information deeper in the call stack.
I don't understand what kind of settings could be different between release and debug could explain this crash.
EDIT 1
Here are the preprocessor definitions I use in debug:
WIN32;_CONSOLE;_DEBUG;__WXMSW__;__WXDEBUG__;_WINDOWS;NOPCH;_USE_32BIT_TIME_T;_CRT_SECURE_NO_WARNINGS
Here are the preprocessor definitions I use in release:
WIN32;NDEBUG;_WINDOWS;_CONSOLE;__WXMSW__;NOPCH;_USE_32BIT_TIME_T;_CRT_SECURE_NO_WARNINGS
Some of them come from wxWidgets
EDIT 2
I have noticed that when I save string in an XML file, they show differently between my release and debug configuraction. It looks as if the release version uses different encoding.
For example "title" shows up as "X�~T"
Other characters like spaces totally change the order of the string and insert special characters that I can not copy-paste (probably \0)
I have made sure that both my configurations are using multi byte character set.
In 100% of my experence, when something succeeds in the debugger, but fails out of the debugger, you've overrun a function local array.
The issue was due to the fact that I was compiling using
Multi-threaded Debug DLL (/MDd)
instead of
Multi-threaded DLL (/MD)
in release mode.