The debugger in Visual Studio 2010 is recently pointing at the wrong lines and/or skipping lines and I have no idea why this is. This is a CUDA project and only happens in CUDA files. I've noticed the following:
It always happens at the same part of the program.
The lines it points to are always the same, i.e. not random.
Putting extra code after the culprit lines changes which lines it points to.
It only happens in .cu-files. Moving the code to a .cpp-file does not recreate the problem.
What I have tried:
Clean and rebuilt the solution.
Install SP1 for MSVC10 and do all possible updates via Windows Updates
Set the compiler to not use optimizations in debug mode for both C/C++ and CUDA C/C++
Manually delete all created files and then rebuild from the solution folder.
Deleting the folder C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
Recreating the solution only using the source files.
Disabling my extensions.
I've managed to reduce the code to the following which might reproduce the problem. Mind that this code has to be inside a .cu-file and most probably needs to be compiled with the cuda compiler for C/C++. Including boost is not really necessary, but this example does show what problems I'm having. A shorter example is at the back.
#include <boost/numeric/ublas/matrix.hpp>
using boost::numeric::ublas::matrix;
struct foo {
foo() : mat(NULL) {}
matrix<float>* mat;
};
bool func(foo *data) {
bool status; // <- skipped line
status = false;
if (status) {
std::cout << "test\n";
return (status); // <- error reported here
}
int size = data->mat->size1(); // instead of here
return status;
}
int main(int args, char* argv[]) {
func(NULL); // force error by passing NULL pointer
return 0;
}
Does anyone have any idea how to solve this or how this could be happening? It's pretty annoying having to debug this way.
Shorter example only showing the skipping lines. No external libraries necessary.
bool func() {
bool status; // <- skipped line
status = false;
return status;
}
int main(int args, char* argv[]) {
func();
return 0;
}
Since the program only contains CPU instructions and variable declarations of types that have no construction contain no instructions, the debugger will not stop there. It just executes instructions and then uses the debugging information that the compiler provided to find the relevant line of source code.
Related
I have a DLL containing multiple functions that can fastly perform arithmetic operations on extremely large integers. My test program runs smoothly in my Visual Studio 2019, as follows.
int main()
{
HINSTANCE myDDL = LoadLibrary(L".\\BigIntDLL.dll");
typedef string (*func)(string a, string b);
func expBigInt = (func)GetProcAddress(myDDL, "expBigInt");
string y= expBigInt("2", "10000");//it can calculate 2^10000 and return it as a string
cout << y;
}
So, I moved the code directly into my Qt project as a part in widget.cpp, and also placed the BigIntDLL.dll and .lib in the same directory of the project. The compilation was successful, but when debugging my interface, the program broke with a Segmentation fault error due to a call to the expBigInt function.
void Widget::on_expButton_clicked()
{
getTextEditNum();
Output=expBigInt(Input1,Input2);//crashed here
writeResult(Output);
}
I am not really sure where the real problem is, but I now suspect that I have not successfully called the functions in this DLL, causing some memory issues.
I am trying out CLion as new IDE and I have this odd problem with debugging. I am trying to step into function cropImage (not method) but all I can get when stepping into is to get to constructor of CRect.
int main ( void )
{
cropImage( "./sample/input_00.raw", "./output_00.raw", CRect(1,2,3,4), ENDIAN_LITTLE);
return 0;
}
Also, when I try to put breakpoint inside function cropImage() it just get ignored. What am I doing wrong? I think this is pretty much basic function of debugger to step into function, not only methods...
I am using CLion on Linux with GDB and g++.
EDIT:
Just to clarify the code and issue here is how the file main.cpp looks
bool cropImage ( const char * srcFileName,
const char * dstFileName,
const CRect & rc,
int byteOrder )
{
// Open streams, create objects, do stuff
}
int main ( void )
{
cropImage( "./sample/input_00.raw", "./output_00.raw", CRect(1,2,3,4), ENDIAN_LITTLE);
return 0;
}
Everything works from CLI ( using gdb on binary created from CLion ), it just that inside of IDE it ignores any breakpoint inside cropImage() function.
So I find this workaround. Ref: https://intellij-support.jetbrains.com/hc/en-us/community/posts/206606815-Integrated-GDB-and-a-frame-not-available-error
Seems like it's issue on ArchLinux. Even though CLion detects gdb automatically without problems, frames doesn't exist and manually specifying path to gdb (/usr/bin/gdb) fixed this.
This is something I have noticed and I do not have the answer to it and it bothers me.
Let's say we have two simple functions.
void foo()
{
std::cout << "Rainbows are cute!" << std::endl;
return;
}
int main()
{
foo();
return 0;
}
Now these two functions are all part of the same cpp file.
If I compile this cpp file on gcc the file will cout "Rainbows are cute!"
but if I were to do it on Xcode or Visual Studio, the cout statement will not display. I mention VS and Xcode because these are two common compilers, used by many.
My question is why does this happen? What is going on in the compilers were one will display the cout statement in the void functions and the others will not?
The printouts will display in VS and Xcode as well. The difference is in how you run this. When you execute your program from Visual Studio, console window briefly pops up, displays the message, and promptly disappears.
To prevent this from happening, you can set breakpoint on return 0 line, and run in debug mode. When the breakpoint is hit, switch to the console window to see the message:
I am now using Boost Unit Test to perform unit test for my project. Every time I run the unit test, I got a memory stack problem. I debug into the source code of BOOST library, and I find that the problem comes from invoking the following codes in unit_test_suite.hpp file:
void
traverse_test_tree( test_unit_id id, test_tree_visitor& V )
{
global_i = global_i + 1;
std::cout<<global_i<<std::endl;
if( ut_detail::test_id_2_unit_type( id ) == tut_case )
traverse_test_tree( framework::get<test_case>( id ), V );
else
traverse_test_tree( framework::get<test_suite>( id ), V );
}
The error information I have obtained from VC10 is:
Unhandled exception at 0x779815de in TestApplication.exe: 0xC00000FD: Stack overflow.
I was wondering what's wrong with the test program. Thanks!
EDIT Based on the suggestions I looked through my codes, and very strange things happen: if the test suite is defined in same program with main(), it works; however, if the test suite is from a .dll, the error will occur. I list the following codes to illustrate my problem:
boost::unit_test::test_suite* main_global_test_suite;
void Hellotestdll()
{
int i= 1;
int j= 2;
BOOST_CHECK(i == j);
}
boost::unit_test::test_suite* get_abc_test_suite()
{
test_suite* ts = BOOST_TEST_SUITE( "unit_geometric" );
ts->add( BOOST_TEST_CASE( &Hellotestdll ) );
return ts;
}
int main( int argc, char* argv[] )
{
try
{
/**
* Step 1. obtain options
*/
char* optionLine[1024];
int len;
len = obtain_options(optionLine, argc, argv);
/**
* Step 2. perform unit test based on user's options
*/
int test_status=0;
main_global_test_suite = get_abc_test_suite();
test_status = unit_test_main(run_global_test_suite, len, optionLine);
return test_status;
}
catch(std::exception& e)
{
std::cout << e.what() << std::endl;
return 1;
}
catch (const std::string& s)
{
std::cout << s << std::endl;
return 1;
}
catch (...)
{
return 1;
}
}
The above codes work very well. But if the test suite is from a .dll, for example:
// dll_header.h
namespace abc
{
ABC_EXPORT boost::unit_test::test_suite* get_geometric_test_suite();
}
// dll_header.cpp
namespace abc
{
using namespace boost;
using namespace boost::unit_test;
void Hellotestdllabc()
{
int i= 1;
int j= 2;
BOOST_CHECK(i == j);
}
boost::unit_test::test_suite* get_abc_test_suite()
{
test_suite* ts = BOOST_TEST_SUITE( "unit_abc" );
ts->add( BOOST_TEST_CASE( &Hellotestdllabc ) );
return ts;
}
}
Then if I invoke this test suite, with the following codes:
int main( int argc, char* argv[] )
{
............
/**
* Step 2. perform unit test based on user's options
*/
int test_status=0;
main_global_test_suite = abc::get_abc_test_suite();
test_status = unit_test_main(run_global_test_suite, len, optionLine);
return test_status;
}
The annoying stack overflow error will happen.
Summery of the Problems
(1) boost dll with MDd (Succeed)
If I link the boost unit test library (with the definition -DBOOST_ALL_DYN_LINK -DBOOST_TEST_NO_MAIN -DBOOST_TEST_DYN_LINK -DBOOST_ALL_NO_LIB)and the running executable program with the same dynamic run-time library (Multi-thread Debug Dll (MDd)), it will work.
(2) boost dll with MTd (Failed)
If the boost unit test library (with the definition -DBOOST_ALL_DYN_LINK -DBOOST_TEST_NO_MAIN -DBOOST_TEST_DYN_LINK -DBOOST_ALL_NO_LIB)and the running executable program are compiled and link with the same static run-time libray (Multi-thred Debu (MTd)), I will have a crash, but the crash is different from the one I reported above:
(3) boost static lib with MDd (Failed)
If the boost is built as a static library (with the definition of -DBOOST_TEST_NO_MAIN -DBOOST_ALL_NO_LIB), and both the boost library and the executable program are built with the same dynamic run-time library (MDd). The following crash will happen:
(4) boost static lib with MTd (Failed)
If the boost is built as a static library (with the definition of -DBOOST_TEST_NO_MAIN -DBOOST_ALL_NO_LIB), and both the boost library and the executable program are built with the same static run-time library (MTd). The following crash will happen:
ABC_EXPORT boost::unit_test::test_suite* get_geometric_test_suite();
The point of unit tests is to find problems in code early. That worked, it is just that you found the problem very early. Too early to even allow the unit test to run properly.
Functions in a DLL that returns pointers to C++ objects are a problem in general. It will only come to a good end when the layout of the C++ object exactly matches the assumptions made by the compiler when it compiled both your DLL and your EXE. And that the object lives on a heap that both modules have access to, required since the DLL creates the object and your EXE needs to delete it.
To allow the object to be properly deleted, both the DLL and the EXE must share the same CRT version. You will get into trouble when you build your program with /MT, asking for the static version of the CRT. The relevant compiler setting is C/C++, Code Generation, Runtime library setting. Your Debug configuration must use /MDd, your Release configuration must use /MD. For both the EXE and the DLL project, as well as the Boost library when it was compiled. If it is /MTd and /MT then the DLL will have its own copy of the CRT linked into it and will use its own heap to allocate from. The EXE cannot properly delete the object since it uses another heap. Doing so anyway will produce undefined behavior. Anything can happen, you tend to only get lucky when you run your program on a version of Windows that's newer than XP. Vista and up will use a debug heap when you run your unit test with a debugger attached, it invokes a breakpoint when it notices that the pointer passed to ::operator delete is invalid. Be sure to allow the linker to automatically find the correct Boost .lib to link to, don't force it yourself.
Object layout is more likely your problem, unfortunately much harder to diagnose. You stay out of trouble by building your EXE and DLL with the exact same compiler settings. With the additional requirement that they must match the settings that were used to build the Boost libraries. Which certainly is the difficult part, that requires a time machine. Particularly the _HAS_ITERATOR_DEBUGGING macro is a troublemaker, basic STL classes like std::vector will have a different layout that depends on the value of that macro.
I realize this is very vague, but there isn't enough info in the question to truly diagnose this issue. A very basic check you can do is putting the returned boost::unit_test::test_suite pointer in a watch expression. If you suddenly see the members of that object change when you step into Boost code then you know you have an object layout problem. What happens next is highly unpredictable, a stack overflow is certainly possible. Yet another diagnostic is to use the Debug + Windows + Registers window. Ensure that the ESP register value is stable when you step over functions.
I am working on VS 2008. I wish to get the following information for all my methods:
1) Time at call entry
2) Time at call exit and the return value.
GDB allows me to set a break point at each function entry and exit and run a script at the breakpoint and then continue debugging. I am tired of looking for solutions to do something similar on VS. I even thought of writing a script to parse my entire code and write fprintf's at entry and exit but this is very complex. Desperately looking for help.
using windbg, you can also set at each function entry and run a script.
For instance the following command will add a breakpoint on all functions of your module, display the name of the function, the current time, run until the function exit, display the time and continue.
bm yourmodule!* "kcL1;.echotime;gu;.echotime;gc"
Basically this is a function level Time-Based Profiling (TBP). Several tools can help you on this:
Visual Studio Profiling Tools: which is available with Visual Studio Ultimate and Premium version only. http://msdn.microsoft.com/en-us/library/z9z62c29.aspx
Intel vTune: It can do lots of things, including function level profiling. http://software.intel.com/en-us/articles/intel-vtune-amplifier-xe/
AMD CodeAnalyst: it is a free tool. It can work with Intel CPU as well (with limited function, but enough for your purpose). It can do source code level profiling: http://developer.amd.com/cpu/codeanalyst/codeanalystwindows/pages/default.aspx
I suggest you to try with AMD CodeAnalyst first. If you don't have Visual Studio Premium or Ultimate edition.
I assume you are suing c++. You can define a time trace class which display the timestamps
/* define this in a header file */
class ShowTimestamp {
private:
static int level_; // nested level for function call tree
private:
const char *func_;
public:
ShowTimestamp(const char* f) : func_(f) {
std::cout << func_ << ":" << (level_++) << ":begin\t" << GetTickCount64() << std::endl;
}
~ShowTimestamp() {
std::cout << func_ << ":" << (--level_) << ":end\t" << GetTickCount64() << std::endl;
}
};
#ifndef NO_TRACE_TIMER
#define TIMESTAMP_TRACER ShowTimestamp _stt_(__FUNCTION__);
#elif
#define TIMESTAMP_TRACER
#endif
The level_ should be declared in a CPP file separately.
// You need to define the static member in a CPP file
int ShowTimestamp::level_ = 0;
In your code, you can do
int Foo(int bar) {
TIMESTAMP_TRACER
// all the other things.
......
return bar;
}
If you don't want to trace timer any longer, you can just define NO_TRACE_TIMER
Visual Studio is not suited for this; you would have to use WinDbg. It has its own scripting language that would allow you to do what you are seeking. Unfortunately I don't know the first thing about it's scripting language; you will have to read the help file (which is actually more-or-less useful, for once).