I'm running a c++ program from R using Rcpp and RcppArmadillo. My OS is windows 8. I use the cxxfunction to compile my code (Later I'll make a package directly instead, but for now I'm clueless about how to make a package). The issue is that R often crash while running my c++ code. There must be some segmentation faults because often it doesn't exactly crash at the same spot even with the same seed. Currently, I'm printing out stuff to the prompt but I feel like this is not the most efficient way to debug my program.
So I read a bit about how to debug c++ code in R and it seems that gdb is a good way to do it. So I downloaded mingwin32 which contains gdb for windows. When I run R using gdb it works fine and I can run all my code fine but when R crash gdb backtrace function returns 'no trace'. I have no idea why. I heard people say to add the option -g -Oo in the compilation, but I'm using cxxfunction to compile my c++ program and I don't know how to compile manually things in R. I also heard some people talk about changing cxxflags but I don't really understand what that is and how to change it.
So my questions are :
Should I use gdb or something else?
How do I get gdb to work with my R program?
Should I install linux on a separate partition to make everything simpler?
Thanks for the help.
Related
I am writing a algorithm using the Eigen library because I am dealing with large number of matrices and performing different operations on them. I am developing the code on Mac OS X Mavericks, and I was trying to debug my code using Xcode and also LLDB through the command line.
Every time I run
expr a.rows()
where a is a variable of type Eigen::MatrixXd, LLDB itself crashes with a segmentation fault.
Am i doing anything wrong or is it a bug?
Yes please do file a report at http://bugreporter.apple.com, with the crash log and if you can make available a small sample project that crashes that would be even better. However, given that this is a complex C++ library you might be running into a known crash in the C++ demangler that shipped with Mavericks. If the crashed thread is free asserting under a call to
lldb_private::Mangled::GetDemangledName()
and then this is that crash. For more info, you can have a look at the Apple Developer Forums post:
https://devforums.apple.com/message/904311
I'm debugging some Fortran code with gdb and it keeps stepping through the C code for intrinsic Fortran functions. For example if I try to step past a write call, it jumps into write.c. Is there any way to stop this behaviour? I'm on CentOS 6.3, with gdb 7.2 and gfortran 4.4.
Normally I think "next" should work. But I don't know Fortran, maybe something funny is going on.
Another way is to ensure that you don't have debug info for the intrinsics installed. gdb will automatically skip over functions that don't have debuginfo if you try to "step" into them.
The final way is to upgrade your gdb and use the new "skip" command, which was added exactly for this use case.
I had a problem like this where next wasn't working when I was remote debugging on a cross-compiled target. I finally realized that I had loaded the wrong executable/symbol table using gdb's file command. Hitting next was jumping in to places un-releated to the current line of code. It was doing the best it could given the information I gave it :)
I'm really lost in here. Maybe some of you can point me to a right direction.
I'm developing a tool in ANSI C using GCC over MinGW. The tool is to be run only from command line. Probably only on windows machine. It elaborates some data locally and generates files for use by other programs. Basically it does a lot of math and a few file handling. Nothing really fancy. I didn't find it necessary posting the whole 1000+ lines here for examination...
I compile it with GCC -ansi making sure not even a single warning is present. Everything worked always well as the development evolved. But recently I started getting (almost) random segfaults. I checked for the last changes made, but found nothing. I removed the last changes completely coming back to when it perfectly worked. Still segfaults. I traced line by line. I went back to read and re-read the whole code searching for possible pointers/malloc errors. I simply can't find the reason for it to fail so often and so randomly.
So here is the strange thing - I compiled it with -g and run through GDB.
start MSYS
change dir where the program resides
$ gdb generatore.exe (the one compiled -g that fails)
$ run
And it perfectly works inside GDB. I went step by step. Line by line. Perfect. I tried stressing it with huge amounts of data. All works. Can't reproduce the error. But if the same executable is run from command line, it fails.
I suspect an unpredictable behavior with some pointer but I cannot find it anywhere.
Has anyone ever encountered anything similar? Where should I be checking? Also, I am not as familiar with GDB, since it runs smoothly, can I enforce the control somehow to find the reason it fails? Are any other free debugging solutions for windows you can advise me? How can I debug for unpredictable behaviors?
Thanks a lot for your attention,
maxim
There is a great free tool for catching all kind of runtime errors to do with pointers, memory allocations, deallocations, etc., which cannot be caught at compile time, so your compiler will not warn you about them: valgrind http://valgrind.org/. The problem is, AFAIK it doesn't run on Windows. However, if your program is pure ANSI C you should be able to build it and run it with valgrind on a Linux box.
I'm not 100% sure about it, but it should run OK in a virtual machine, so if you don't have a separate Linux computer you can try installing e.g. Ubuntu in Virtual Box or VmWare and try running your program with valgrind in it.
I have developed a library using C++ and C; and the library is working fine with my C++ test program; but it gave me a segmentation fault when the library is used in Python using c_types.
Also, my library works fine under 64 bit OS when I use c_types or C++ test program, it crashes when I switched to 32 bit OS. And my C++ test program works fine on 32 bit OS.
This is very weird.
Anyone knows how to debug the Python and c_types library together?
Or do you have any suggestion?
The right is to do it is to launch gdb with pdb.
An example here : calling functions returned as pointers from other functions in ctypes
I think this answer is better:
runing python in gdb
In a summary, just run the following:
gdb python
//after gdb is running, type the following command
run test_case.py *arguments_of_your_script*
gdb will stop when it find a segmentation fault in the python c_types library.
After that, just run the common gdb command to examine the memory and registers.
I have just started to get experiment with C++ on my MacBook Pro, and am very new to it all. Through research, a few different people have suggested to use TextWrangler for writing the code. I have put together some of the code that the beginning of a tutorial has given me, but I am now unsure how to run it through TextWrangler. I know that you are supposed to compile it first, but that is mostly where I'm stuck. I have downloaded Xcode so I have gcc, but I don't know where to go from there. And after I have compiled it, is there a simple way to run the file? Like I said, I am very new to all of this and may be looking at it in the wrong way.
TextWrangler is only a text editor, you still need a compiler to compile your code and then you need to run your code.
Xcode (which is an IDE) does all that for you so the confusion is understandable.
for now opening a terminal and doing g++ filename.cpp to compile and ./a.out to run your program will get you going. But you really have to learn to use a IDE or how to write a makefile.