GLUI runtime error with release build - c++

I'm developing my first application using GLUI and I'm having some problems. I'm using Visual Studio 2010 on a Windows 7 machine and using glui-2.35. My application runs fine when built in debug mode but crashes with a runtime error when built in release mode. From the debugger the error is from the last statement in this function from glui.cpp:
void GLUI_Master_Object::set_glutReshapeFunc(void (*f)(int width, int height))
{
glutReshapeFunc( glui_reshape_func );
add_cb_to_glut_window( glutGetWindow(), GLUI_GLUT_RESHAPE, (void*) f);
}
I'm not sure why the release build crashes; any suggestions would be greatly appreciated.

I'm not an expert in MSVC++ debug and release mode but I've been looking for some information, and in this website, some users talk about it.
One of them (#mcdeeiis), in this page, says:
...
In a debug build the complete symbolic debug information is emitted to help while debugging applications and also the code optimization is not taken into account.
While in release build the symbolic debug info is not emitted and the code execution is optimized.
Also, because the symbolic info is not emitted in a release build, the size of the final executable is lesser than a debug executable.
One can expect to see funny errors in release builds due to compiler optimizations or differences in memory layout or initialization. These are usually referred to as Release...
Anyway, check sure the libraries that GLUI or your project depends on, have been compiled with release mode too. It might cause problems.

Related

Release version crashing due to msvcp120d.dll

My code is crashing in the Release configuration but not the Debug configuration. It's only doing this as I exit the program as the very last line 'return(0);' executes. I'm working in the Visual Studio development environment and when it crashes, VS studio offers me the option to 'Debug' the code. When I select that, it leads to an error dialog that pops up saying:
Unhandled exception at 0x00007FF851A0512D (msvcp120d.dll) in myapp.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
When I select to 'break' when this exception occurs, it highlights the following function in the xstring file:
void _Free_proxy()
{ // destroy proxy
typename _Alloc::template rebind<_Container_proxy>::other
_Alproxy;
this->_Orphan_all();
_Alproxy.destroy(this->_Myproxy);
_Alproxy.deallocate(this->_Myproxy, 1);
this->_Myproxy = 0;
}
And, especially, the line '_Alproxy.destroy(this->_Myproxy);' is highlighted as the culprit.
I thought the issue might be that my 'release' code is somehow linking to the 'debug' msvcp120d.dll library since that's highlighted in the 1st dialog that pops up - but that may be just because I start using the VS debugger to ID this problem. But even if that is the problem, I'm uncertain how to tell VS to compile with msvcp120.dll for the Release configuration and msvcp120d.dll for the Debug configuration.
(For the record, I'm generating all my code using the 'Multi-threaded DLL (/MD)' flag in the Release configuration and the 'Multi-threaded Debug DLL (/MDd)' in the Debug configuration)
The kicker is that when the Release version crashes, the process enters a 'suspended' state and I'm unable to fully kill it via task manager. And then I can't even recompile a new Release version without restarting my computer!
I don't know how to isolate this problem. Can anyone advise me on how I might fix this?
Update
The code for this project is quite large - so distilling it to a minimal version that exhibits the same behavior, while usually a valid way to track a bug, would be a pretty big task. I was hoping that there was some method to log the processes and figure out which one is calling msvcp120d.dll #Niall, I generated the dependency graph and it is huge. Without giving away anything proprietary, attached is a global view of the graph.
Dependency graph of entire solution
Is there any tool to track which is calling msvcp120d.dll?
#Niall Thank you! The software at Dependencywalker.com was fantastic. I was able to use it to determine the library causing the problem and track down the error. It turns out that I had previously (months ago, dumbly) set a system path to the debug version of that library. So even though my project was properly directed to link to the release version of the library, at runtime, my executable was linking to the debug version of the *.dll file!
I deleted the path variable and now make sure a copy of the proper *.dll file is in my Release or Debug directory. Then it all runs and shuts down fine.
Thanks to all who provided assistance.

Cause of WP8.1 release build exception: "System.IO.FileNotFoundException: The specified module could not be found"?

I'm posting a problem I recently encountered while developing a Windows Phone 8.1 release mode app. Fortunately, I was able to solve the problem, which I would like to share via StackOverflow.
The problem encountered was as follows:
I have a Windows Phone 8.1 (WP8.1) application which has a Windows Runtime Component.
When compiled in debug mode, the application works perfectly.
When I build it in release mode, the application links and runs. However, when the C# portion attempts to instantiate the Windows Runtime Component class, the app throws a System.IO.FileNotFoundException exception, caught by Application_UnhandledException() in App.xaml.cs:
System.IO.FileNotFoundException: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at System.StubHelpers.StubHelpers.GetWinRTFactoryObject(IntPtr pCPCMD)
. . .
I attempted to debug the release version, disabling all optimizations in the project, but the results were not conclusive. The breakpoint I placed on the native code constructor was never hit by the debugger (I switched debugging to "Native Only" in Properties>Debug).
Reviewing the compiler and linker settings did not show anything out of the ordinary. What was the cause of the problem?
The reason for the System.IO.FileNotFoundException being thrown was because the list of libraries to link in release mode (Linker>Input>Additional Dependencies) included SQLite3D.lib (the debug version of the SQLite library) rather than SQLite.lib (the release version):
API.lib;Internals.lib;JSON.lib;sqlite3D.lib;%(AdditionalDependencies)
This was enough to prevent Windows Phone 8.1 from loading the Windows runtime component DLL to invoke the class constructor.
The solution was to link the release lib rather than the debug one:
API.lib;Internals.lib;JSON.lib;sqlite3.lib;%(AdditionalDependencies)
This explains why the app works perfectly in debug mode.
My experience in C/C++ has taught me that mixing debug and release libs can be problematic. An example is allocating memory in a release mode DLL and deallocating the memory in a debug mode DLL, because there are two different memory management systems at play here. The case at hand illuminates another reason for not mixing release and debug DLLs/libraries.

C++ link issue after switching to /MT

I am working on application which should be running on any Windows NT machine. Today I was trying to deploy my application on new machine and suddenly get error that msvcp100.dll is missing. I've started digging into that problem and found solution. Only what I had to do is in project configurations change Run time library From /MDto Multi-threaded (/MT).
But after switching to current mode I am getting link error. Not sure why and how to fix it. Could you please help me to figure that out? Thanks!
You aren't supposed to deploy debug builds. Compile with Release settings (including release version of the run-time library) and you won't have that problem. (You can enable debug information on a release build... it's use of the debug libraries that causes problems)
The error comes from that when compiling in debug mode, you'll need to change your project to link with link with debug libraries, ie msvcmrtd.lib instead of msvcmrt.lib and msvcrtd.lib instead of msvcrt.lib
Deploying debug binaries to other machines may/will cause runtime problems though since the debug version sof the DLLs aren't (afaik) redistributable, what you probably want to do is to fix your release build.

how can i diagnose exception in window 7 release mode compilation with VC 2008

i have strange problem , my application (exe) is working fine in debug mode in windows 7
but stop to work with exception when compiling in release mode .
how can i debug the program to find what is causing the exception this is application with more then 300,000 lines of code ..
Compile in Release mode but create the .pdb files: How to generate PDB’s for .net managed projects in release mode?
Deploy the .pdb files to same folder as the .exe.
Then attach to process.
Check the projects settings which are different for debug and release modes, maybe you will find an answer there.
Compile release mode with debug information and turn off optimization. You will have debug version compiled with release defines. If it fails the debugger will show you bad place.
Just turn off optimization. Once upon a time that was an issue for me. In this case it will be really hard to find out the cause.
Create PDBs, it can be done for native C++ too.

How does building a project in Debug differ with in Release?

In visual studio or any other IDE, usually there are two build configurations, Debug and Release?
How does the differ? Why sometimes you have compile errors when building in Debug mode, but not when in Release mode, and vice versa?
Debug compiles with symbols and allows you to "see" your code when it runs. It also does some initialization of variables to help in the bug tracking process.
Release is generally optimized, and does not generate debug data.
Generally when you get compile issues toggling between the two, it relates to hard coded paths to folders.
MSDN on configurations
The debug build is created with some embedded information (symbols) which allows the debugger to debug the application and exposes the runtime behavior of the application. On the down side, the debug build is a bit slower and inefficient in execution and has a bigger memory footprint.
Source:http://www.programmersheaven.com/2/FAQ-VISUALSTUDIO-Debug-Release