Analyze a core dump generated by a CGO application

[mattv3x]

Hi,
we have a C++ application dynamically loading at runtime a shared library written in GO and implementing a C interface throw CGO.
Sometime the application crashes during a call to one of the interface's APIs, so, apparently, the crash happens during the execution of the GO code: the analysis of the core with GDB shows the stack until the call of the CGO function, something corrupted after that (as it would be the stack for other threads...).
No panic stack or other error are generated to standard output/error.

Do you think we can use delve to analyse the generated core? Do we have to set something particular?
Consider that the problem always happens on production machine, that we cannot directly access to debug.

Any help is really appreciated.
Thanks

[aarzilli]

We never put in any work into debugging C++ code, but it does understand cgo to some extent. Disabling optimizations for the C++ library (CFLAGS="-O0 -g")would make things better, but if it only happens in production you probably can't do it.
You say that the crash happens while executing go code, but also that the top of the stack is C++ functions, how does that work?
Anyway, make sure to take a look at the documentation for the stack command, in particular using different values for the -mode parameter could be useful.

[mattv3x]

The main applications is written in C++. It loads shared libraries at runtime; the crash occurs while executing a function provided by a library written in GO that implements, through CGO, the interface expected by the main application (it is built with the "-buildmode=c-shared" option).
To troubleshoot the issue, we are using the main C++ application built with debuggable options; the stack is clear until the invocation of the library's function, so we are almost sure that the crash is generated by the GO code (or the CGO interface). The problem is that we don't have anything clear "after" the function to try to understand more. We are looking for a way to analyse the core "inside" the GO function.

[aarzilli]

Ok, I see now. We never did anything to support c-shared builds, it likely won't work. I've never even looked into what would be needed to make it work.