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.
Related
I am reproducing the following behavior in VS2008 (native C++):
attach to an executable that consumes a custom dll (for which I have the source)
debug the code from the dynamic lib
encounter an access violation error (probably caused by the code in the executable - closed source)
break on access violation error with the attached debugger
After this, no matter how many times I reattach, rebuild, restart the application, computer, any breakpoint I will set in the .dll source code becomes inactive (No executable code associated with this line is the alleged cause, according to VS).
I suspect this is an issue with VS2008, as I did the same on a different machine and now I have two machines where debugging is no longer possible.
Are there any recorded solutions of this issue? What can be done to overcome it?
What I have done:
deleting everything (the entire solution, pdbs, binaries, etc.) and starting with the code from scratch (cloning the latest version from the repository)
restarting the machine
changing the machine (it worked once, until the error occurred, then the other computer exhibited the same behavior)
What I cannot do:
change compiler/VS version
debug the executable (sadly no source code available and lack of assembly skills)
The root of the issue was more subtle. Although the project was intended to be native C++, I have found that on the configuration I was testing the code, the entire project was built with CLR support.
When attaching to the application the first time on any machine, in native debugging mode, the breakpoints would trigger. However, when encountering the native access violation error, these breakpoints became permanently inactive thereafter. After deciding to check what happens if I let the debugger attach in auto mode, I have discovered that the breakpoints became active and hence found out that all code had been compiled with the /clr flag except for the entrypoint in the consumed dll, which had no CLR support.
The question here is why VS2008 behaves like this and does not directly disable breakpoints whenever one attempts to debug a managed context using native debug settings.
TL;DR: check if your C++ project is built with CLR support and attach either as native or managed, depending on your needs. Alternatively, if only some of your files require C++-CLI usage, enable the /clr flag only for those. It is more often a better choice since C++-CLI often clashes with certain native libraries (e.g. not std::mutex support, linking against native static libs Linking unmanaged C++ DLL with managed C++ class library DLL, etc.).
I am writing a program using OSG and I would like to step through it to see how stuff works, change a few lines and debug again. However every time I need to load a file using osgDB plugin for openflight. The debug version of the plugin works quite slow. I have no intention of debugging the plugin itself, so I figured I might as well use the release dll. I read that I can do this as long as there are no memory allocation in program and freeing in dll or visa versa and if the dll was designed to avoid problems that might occur with release/debug mixing. I'm not sure if osgdb_openflight.dll was designed like that.
My question: can I use the release plugin dll in my debug build, and how can I make my program use it?
UPD: I achieved my goal following the #XenonofArcticus's advice.
Some additional thoughts on the topic for the sake of better understanding:
I also tried to simply rename the release dll, so it would get loaded in the debug build. (I thought this would work, because I usually use release dlls in debug builds - Windows's, SQL's and other 3rd party dlls, that do not come with debug info. Also see Igor Tandetnik's comments on this question). It did and the program didn't crash, however it also didn't load the file. Apparently this particular dll wasn't designed to be used in debug builds. Any other explanation?
I'm not sure you're going to achieve what you want trying to mix debug and release. However, perhaps it would work to build a release with debug symbols target? This can allow you to do SOME debugging, but it's still a release build and behaves like one.
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.
What are the 'best practices' when it comes to debugging core dumps using GDB?
Currently, I am facing a problem:
The release version of my application is compiled without the '-g' compiler flag.
The debug version of my application (compiled with '-g') is archived (along with the source code, and a copy of the release binary).
Recently, when a user gave me a core dump, I tried debugging it using
gdb --core=./core.pid ./my_app_debug-bin
The core was created by my_app_release-bin. There seems to be some kind of mismatch between the core file and the binary.
On the other hand, if I try
gdb --core=./core.pid ./my_app_release-bin
the core matches but I am unable to get source code line numbers (although I get the function names).
Is this what is practised? Because I feel I am missing something here.
It sounds like there are other differences between your release and debug build then simply the absence/presence of the -g flag. Assuming that's the case, there is nothing you can do right now, but you can adjust your build to handle this better:
Here's what we do at my place of work.
Include the -g flag when building the release version.
Archive that version.
run strip --strip-unneeded on the binary before shipping it to customers.
Now, when we get a crash we can use the archived version with symbols to do debugging.
One thing to note is that if your release version includes optimization, debugging may be difficult even with symbols. For example, the optimizer can reorder your code so even though the debugger will say you crashed on line N, you can't assume that the code actually executed line N-1.
You need to do some additional stuff to create binaries with stripped debug information that you can then debug from cores. Best description I could find is here
No, you don't miss anything. debug and release are just different binaries, so the core files of release don't match the debug binary. You have to look at machine code to get something from the release core dump.
You probably have to ask your user how the crash happened and collect additional log information or whatever you app produces.
Recently I have discovered that my release executable (made with msvc++ express 2008) becomes very large. As I examine the executable with a hex viewer I saw that only the first 300k bytes contains useful data the remaining bytes are only zeros - 6 megs of zero bytes.
The debug built exe has 1MB size, but the release is 6.5MB.
Why does MSVC++ express do that useless thing? How can I fix it?
Did you define large arrays at file-scope in your program? That might be one reason. You can use the dumpbin program to see how much space each section in the exe file takes, that should give you a clue to the "why".
Perhaps you are statically linking your .exe in release, but dynamically linking in debug? Check this is the dialog Project Properties.
Another possibility is that in release mode a lot of functions are inlined or you are using a lots of templates.
You can tell the compiler to optimize for size in the dialog Project Properties.
Release 6 times larger than Debug - something is probably wrong.
Try to create a fresh project and just copy your source code. Compile it and see what you get for the Debug and Release executables.