This question already has answers here:
Why does java app crash in gdb but runs normally in real life?
(2 answers)
Closed 8 years ago.
I wrote a C++ program. It invokes some functions provided by libhdfs(HDFS API for C++, implemented with JNI) and it runs OK when normally executed. When I use gdb to launch the program and input run command. The program fails to run and I got the following error message in gdb context:
[Thread debugging using libthread_db enabled]
[New Thread 0x40100940 (LWP 18482)]
[New Thread 0x40201940 (LWP 18483)]
...
[New Thread 0x41514940 (LWP 18502)]
Program received signal SIGSEGV, Segmentation fault.
0x00002aaaac26c862 in ?? ()
I use command shell echo $CLASSPATH in gdb context. It shows the correct HDFS related environment.
I searched with Google and StackOverflow. But I did not get any idea.
Any tip?
Why does java app crash in gdb but runs normally in real life? provided a solution:
handle SIGSEGV nostop noprint pass
While, it is not so elegant.
Related
I am attaching a running process in linux platform using gdb.
gdb -p <pid>
Setting the breakpoint, say
b test.cpp : 23
Now continuing
c
After this when i perform some operation destined to attached process, getting the below error in gdb console:
(gdb) c
Continuing.
[New Thread 0x7409fb70 (LWP 8530)]
Cannot get thread event message: debugger service failed
Please help me how to proceed further.
Additional details:
Its icc compiler, compiling with -g flag enabled
We're running squid from with gdb - that way we can automatically generate backtraces for debugging.
backtrace=`mktemp`
gdb -q -x /etc/service/squid3/gdbcommands /usr/sbin/squid 2>&1 >$backtrace
/usr/bin/mail -s "`hostname`: Squid was restarted (backtrace)" someaddress#charite.de < backtracetrace
rm $backtrace
/etc/service/squid3/gdbcommands contains:
set args -NsYC
handle SIGPIPE pass nostop noprint
handle SIGTERM pass nostop noprint
handle SIGUSR1 pass nostop noprint
handle SIGHUP pass nostop noprint
handle SIGSEGV stop
handle SIGABRT stop
run
set print pretty
backtrace full
generate-core-file
quit
But, every now and then, squid is "just" being stopped & restarted, with no crash being involved at all. In that case I'm still getting an email containing:
Reading symbols from /usr/sbin/squid...done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Inferior 1 (process 57867) exited normally]
/etc/service/squid3/gdbcommands:10: Error in sourced command file:
No stack.
(gdb) quit
And of course there's no stack, since the program exited ok.
How can I change my gdbcommands file to avoid this?
This can be done using either Python or the gdb CLI. Since the CLI is a bit simpler, when possible, I'll sketch that approach.
First, you might as well only create a core file on a bad exit. And, we'll use the gdb exit code later, so let's arrange for that to tell the calling script what happened.
Where your current script says:
backtrace full
generate-core-file
quit
... instead use:
if !$_isvoid($_exitsignal) || (!$_isvoid($_exitcode) && $_exitcode != 0))
backtrace full
generate-core-file
quit 0
end
quit 1
Then your calling script can check the exit code of gdb:
if gdb your args here; then
mail results
fi
I am compiling the unit tests (via GoogleTests) for my program and whenever I try to compile in DEBUG mode on Solaris 11.3 with Eigen 3.2.x, I'm getting this SIGSEGV error then core dump when running the program in gdb:
(gdb) r
...
[Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)]
Program received signal SIGSEGV, Segmentation fault. [Switching to
Thread 1 (LWP 1)] 0x0830fc30 in
Eigen::internal::ploadu (
from=0xfeffe5a0) at ./eigen/Eigen/src/Core/arch/SSE/Complex.h:307 307 {
EIGEN_DEBUG_UNALIGNED_LOAD return Packet1cd(ploadu((const
double*)from)); }
(gdb)
When print from in gdb this is what I'm getting:
gdb p from: (const std::complex< double > *) 0xfeffe5a0
This SIGSEGV only on Solaris, and only when compiling with -Og. I've compiled and tested it on multiple other OSes and there are no issues whatsoever. Is this a known issue? It looks it has to do with some SSE optimizations and alignments, however I cannot pinpoint what exactly is going on.
I am using CentOS 6.3 64 bit and trying to develop a c++ application using IBM® Data Studio
Version 4.1.0.1 which is a flavor of eclipse. I have written a multithread application and all was going well till I tried to do file IO.
I used ofstream to write my data to a file . But this is not allowing me to debug this snippet of code, If I place any breakpoints it shows a break point can not be placed .
I have written this piece of code in a thread (pthread)
ofstream myfile;
char chFileName[100];
sprintf(chFileName,"Json_%s_%s_%d",strType,strGroupID,iIndex);
myfile.open (chFileName);
myfile << strJSON;
myfile.close();
Here is the console output before the application and thread terminates.
[Thread debugging using libthread_db enabled] [New Thread 0x7fffe9f1e700 (LWP 28380)] [New Thread 0x7fffe951d700 (LWP 28381)]
[Switching to Thread 0x7fffe951d700 (LWP 28381)] [Thread 0x7fffe951d700 (LWP 28381) exited] [Thread 0x7fffe9f1e700 (LWP 28380)
exited]
Is it not wise to perform file IO in a thread ?
Could someone please help me with how to fix this issue ?
I am unable to move forward in getting to see the core dumped.
I have got this when i typed
gdb normal_estimation core
Reading symbols from /home/sai/Documents/pcl_learning/normal_estimation/build/normal_estimation...(no debugging symbols found)...done.
warning: core file may not match specified executable file.
[New LWP 11816]
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `./normal_estimation'.
Program terminated with signal 11, Segmentation fault.
#0 0xb53101d6 in free () from /lib/i386-linux-gnu/libc.so.6
(gdb)
Please let me know what should i do?
Program terminated with signal 11, Segmentation fault.
#0 0xb53101d6 in free () from /lib/i386-linux-gnu/libc.so.6
The first command you need to learn is backtrace (or its synonym: where).
This will tell you which code invoked the free, which crashed.
However, it is possible that that code has nothing to do with the actual problem: any crash in free is always caused by heap corruption of some sort (freeing un-allocated memory, freeing the same memory twice, writing to memory that has already been freed, or overflowing an allocated buffer).
The most useful tools to diagnose heap corruption on Linux are Valgrind and AddressSanitizer. Chances are either of these tools will tell you exactly what you are doing wrong.