I have a simple receiver application with USRP B200. It works fine in release mode but crashes in debug mode. Program crashes when following method is called.
uhd::usrp::multi_usrp::make(args)
Here the stack view when it crashes:
The program only requires libboost_thread from the boost library. I tried with different versions (libboost_thread-vc141-mt-x64-1_69.lib, libboost_thread-vc141-mt-gd-x64-1_69.lib, libboost_thread-vc141-mt-sgd-x64-1_69.lib) of that library but got the same result.
Environment :
OS: Windows 10 and 11
Compiler: MSVC2017, MSVC2015 64 bit
UHD version: 3.15.0.0 and 4.1.0.5
Boost versions : 1.69, 1.69, 1.77 and 1.79
Libusb version: 1.0 (debug mode dll)
Edit:
This program works stably in release mode. Also, a similar program like this one works fine in release and debug modes on Ubuntu, but crashes in debug mode on Windows. So, I don't think it's a hidden bug causing the crash. I suspect there is a point between UHD, Boost, and MSVC for the debug mode in Windows. I would be grateful for any help.
I found the problem. The same build configuration must be used for UHD binaries. Using release built uhd.dll in debug mode causes the crash.
Unfortunately, The official build of UHD doesn't contain debug builds. Those who need the debug version, need to compile it themselves. Here is the build guide:
https://files.ettus.com/manual/page_build_guide.html
And here are the debug builds of mine for testing purposes.
https://github.com/huzeyfe-erkek/UHD-binaries
Related
I am trying to step through a C/C++ program (MapServer) in Visual Studio, but I cannot see the local variables.
I created a new project by adding the main .exe I built from source. I can set break points and step through the program without problem, but I cannot see what is stored in any of the variables. I am running all this on a Virtual Machine - the host OS is Windows 10, and the VM is Windows 7.
The program is:
built as a debug release
has no optimizations
the symbols load fine
I am fairly certain it is due to it being a x64 bit release, as I can use the exact same approach for a x32 build and see the variables.
Example of the x32 debugger (the first 5 variables are correct - the others are unset):
Example of x64 debug session (note the program works fine):
I thought it may be due to VS2008, so I also tried in VS2015, but had similar (failing) results:
Trying to access variables in the Immediate Window produces:
// working VS2008 x32 build
map->name
0x00ffcb40 "WFS_server"
// VS2008 x64 build
map->name
0x0000000000000000 <Bad Ptr>
// VS2015 x64 build
map->name
0x0000000000000000 <NULL>
Am I missing some debugger setting in Visual Studio to set the debug project to x64? Or is there some casting issue in the source code that produces this?
Any pointers appreciated..
The above was caused by stdrup being deprecated on Windows, and the heap becoming corrupted.
The MapServer issue on GitHub can be seen at https://github.com/mapserver/mapserver/pull/5277
This question also describes a similar issue: Heap corruption with strdup
So, I'm using CodeLite on Windows, building with Mingw64 on 64 bit system. Everything builds, but when i run the application, it crashes with "Client.exe" has stopped responding. Client.exe being my application. I'm literally running the default example code off the SFML website. When I've googled around for quite some time now and I honestly have no idea as what to even look at for this error.
Sometimes my console will output
Application has exited with error code: 255
But most of the time it outputs:
Program exited with return code: -1073740940
Using help from the comments on my question.
As stated by Satus, The issue was, first, my libraries were statically linked, using the Dynamic libraries, instead, seemed to have fixed my issue. My second issue was that my SFML libraries were built using the wrong version of MingW. Recompiling this was simple enough. I downloaded the SFML source code. Used CMake to set everything up as displayed on the official SFML compiling and building tutorials, and built it using my version of MinGW. After copying the newly compiled DLL's and Debug DLL's, everything worked perfectly.
Be sure if you're using two different version of MingW (64bit and 32bit) to compile each version in CMake accordingly, otherwise you may get issues.
My program crashes in Win/Maci release build, but works in Linux debug/release build and Maci/Win debug build. This is a large program, and I have not simplified it to a code that I can present here yet.
I have read related discussions here. For example,
What are some reasons a Release build would run differently than a Debug build
Program only crashes as release build -- how to debug?
Given that my code works in linux in both release/debug build, while fails only in Win/Maci release build, does this reduce the possibilities that I should look into?
Many thanks.
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.
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.