Eigen c++ debugging using LLDB - c++

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

Related

debugging a c++ program withing R

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.

gdb is very slow when running with netbeans and c++

I am trying to debug a c++ linux program using netbeans and its very slow.
when looking at the netbeans debugger console, I see that it's using gdb and making it printout a lot of information about call stack and variables. I don't need all the information, how do i make netbeans stop asking for it?
More specifically. Netbeans keep calling stack-list-arguments. my stack is very verbose, so is causes about 10 seconds delay for each single step

c++ program terminating when one thread has access violation - how to catch this in linux - for win32 I get stacktraces in vs2010

c++ program terminated with no exceptions or stacktrace
I have a multi threaded application
If one of my threads has an access violation with reading out of bounds on an array (or any seg fault condition) my entire application immediately terminates.
If this happens on my windows counter part using visual studio I get a nice stacktrace of where the error was, and what the issue was.
I desperately need this type of debugging environment to be able to succeed at my project. I have too many threads and too many developers running different parts of the project to have one person not handle an exception properly and it destroys the entire project.
I am running Fedora Core 14
I am compiling with gcc 4.5.1
gdb is fedora 7.2-16.fc14
My IDE is eclipse Juno I am using the CDT builder
my toolchain is the cross GCC and my builder is the CDT Internal Builder
Is there ANY setting for the gdb or gcc or eclipse that will help me detect these type of situations?
That's what's supposed to happen. Under Unix, you get a full
core dump (which you can examine in the debugger), provided
you've authorized them. (ulimits -c—traditionally, they
were authorized by default, but Linux seems to have changed
this.)
Of course, to get any useful information from the core dump,
you'll need to have compiled the code with symbol information,
and not stripped it later. (On the other hand, you can copy the
core dump from your users machine onto your development machine,
and see what happened there.)
You're definitely looking for core dumps, as James Kanze wrote.
I would just add that core dumps will show you where the program crashed, which is not necessarily the same place as where the problem (memory corruption etc.) occurred. And of course some out-of-bounds reads/writes may not exhibit themselves by crashing immediately.
You can narrow the search by enabling check for incorrect memory allocations/deallocations in glibc. The simplest way is to set environmental variable MALLOC_CHECK_. Set it to 2 and glibc will check for heap corruption with every memory allocation/deallocation and abort the program when it founds any problem (producing a core dump, if enabled). This often helps to get closer to the real problem.
http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html

Debug C programs in Python c_types

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.

Help with debugging Qt code

Hi I got couple of questions regarding debugging Qt Code using QtCreator.
I primarily use mac for Qt development but also use win32. So to debug Qt code do I need to install debug library on both?
Say in my application I'm deleting a pointer twice. In small application I can just scan the code and figure out (at least I'll give it a try). In a big application I know I'm deleting location 003E0000 twice. Then what is the best way of determining what is being deleted and who are trying to delete it (preferably using debugger that comes with QtCreator).
Yes you have to...
I suggest you to use valgrind memcheck. It works on linux and mac (I don't know whether it has windows version) and it replaces malloc and free methods and shows much information about memory handling.
valgrind --tool=memcheck