Linux core dump analysis using Visual GDB

[bhat_a]

Hi folks,

I need a help regarding analysis of Linux core dump using visual GDB.
My application is developed on visual studio 2012 and cross compiled to Linux target (using propietery tool). I have generated a core dump on this Linux system
and I want to analyze this core dump file in visual GDB.

I have come across this tutorial :   http://visualgdb.com/tutorials/linux/coredump/

But, one thing is that I want to do a postmortem debug using core dumps.
But in this tutorial, it attaches to the Linux system (in step 9 : Debug Linux app on : system connection).
So, how can I do a postmortem debug using coredump without attaching to Linux system ?

Thanks,

 

[support]

Hi,

You can do that with the latest VisualGDB 5.2, but you would need a cross-gdb for that (you can use one of the versions shipped with our toolchains). Simply check the “Use a cross-compiler on the Windows machine” checkbox and specify the path to your gdb executable.

[bhat_a]

Hi,

I used the cross-gdb for our application in Quick debug feature.

Please find the image below for all the details :

https://drive.google.com/file/d/0B_4tjTG5CRMwejIwb2l6ZHRzYkk/view?usp=sharing

And then in Visual Studio 2012, I do get the following error : Cannot access memory at address (<some hex number>). Please see the image below for details :

https://drive.google.com/file/d/0B_4tjTG5CRMwZEhrOUw0OFA4eXc/view?usp=sharing

Thanks,

 

 

 

[bhat_a]

One more update :

“use cross compiler on the windows machine” doesn’t work with Quick Debug feature.  That means, Cross-GDB doesnt able to locate the call stack and other details in the core file.

But it works perfectly when I used GDB available on the Linux remote system.

But, our purpose is to do a core dump (from linux) analysis on Visual Studio locally without attaching to remote linux system. Is there any solution for this ?

 

 

[support]

Hi,

Looks like you are trying to view a dump related to a shared library. In that case you would need some extra steps to ensure the symbols are read properly:

1. Copy the main executable that corresponds to the dump on your Windows machine and specify it in the Quick Debug settings instead of the .so file.
2. Copy the .so file with symbols and any other relevant .so files to a directory on the Windows machine (e.g. c:\symbols) and run “set solib-search-path c:/symbols” via the ‘enter additional startup commands’ option so that GDB can locate the libraries.

You can check that the symbols for .so files have been loaded by running the “info shared” command via the GDB Session window. If they are not loaded, please double-check the listed libraries, symbol files and the search path.

The “cannot read memory” error is not related to symbol handling. Most likely gdb tries to some heuristics while unwinding the stack (or Visual Studio tries to follow a pointer) and reaches an area of memory that is not included in the dump file. This is normal and should not interfere with the rest of the functionality.

[Author]

Posts