Komodo Edit crashed on my system , and i tried to debug it , added '-g' option inside komodo script,
And i got:
[New Thread 0xa80c2b70 (LWP 5102)]
[New Thread 0xa78c1b70 (LWP 5107)]
Program received signal SIGSEGV, Segmentation fault.
0xa97e1f10 in ?? () from /usr/lib/librsvg-2.so.2
(gdb) bt
#0 0xa97e1f10 in ?? () from /usr/lib/librsvg-2.so.2
#1 0x00000000 in ?? ()
(gdb) c
Continuing.
Operation not permitted
Is there any way to find out the real problem here ?
I wanted to know where that last string 'Operation not permitted' come from , but how ?
Many thanks !
added '-g' option inside komodo script,
When you say this, do you mean that you passed -g as a command-line argument?
If so, that won't work. -g (or -ggdb) needs to be passed to gcc, during compilation of Komodo Edit, so that debugging symbols are included in the output.
Related
This question already has answers here:
Debugging core files generated on a Customer's box
(5 answers)
Closed 2 years ago.
So I have my core dump after setting the ulimit: (ulimit -c unlimited)
The core dump comes from another system that is experiencing some issues.
I have copied the core over to my dev system to examine it.
I go into gdb:
$ gdb -c core
...
Core was generated by `./ovcc'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fedd95678a9 in ?? ()
[Current thread is 1 (LWP 15155)]
(gdb) symbol-file ./ovcc
Reading symbols from ./ovcc...
(gdb) bt
#0 0x00007fedd95678a9 in ?? ()
#1 0x0000000000000002 in ?? ()
#2 0x000055e01cd5e7e0 in ?? ()
#3 0x00007fedd21e9e00 in ?? ()
#4 0x0000000000000201 in ?? ()
#5 0x000055e01cd5e7e0 in ?? ()
#6 0x0000000000000201 in ?? ()
#7 0x0000000000000000 in ?? ()
(gdb)
I check the compile and link commands and they both have "-g" and I can visually step through the program with the codium debugger!
So why can't I see where the executable is crashing?
What have I missed?
Is the problem the fact that the core was created on another system?
Is the problem the fact that the core was created on another system?
Yes, exactly.
See this answer for possible solutions.
Update:
So does this mean I can only debug the program on the system where it is both built and crashes?
It is certainly not true that you can only debug a core on the system where the binary was both built and crashed -- I debug core dumps from different systems every day, and in my case the build host, the host where the program crashed, and the host on which I debug are all separate.
One thing I just noticed: your style of loading the core: gdb -c core followed by symbol-file, doesn't work for PIE executables (at least when using GDB 10.0) -- this may be a bug in GDB.
The "regular" way of loading the core is:
gdb ./ovcc core
See if that gives you better results. (You still need to arrange for matching DSOs, as linked answer shows how to do.)
I'm experiencing segmentation faults in the fglrx dri library when running my own Qt based OpenGL application. The backtrace I get from gdb (with dbg symbols installed for Qt and my own application):
Thread 1 (Thread 0xb7fd9720 (LWP 1809)):
#0 0x06276705 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#1 0x000020dc in ?? ()
#2 0x000020d9 in ?? ()
#3 0x00000000 in ?? ()
I can not see where from my code I call the fglrx function which causes the segmentation fault. How could I extend this backtrace to see it completely from the main() function down to the fglrx dri library?
edit: To confirm my own application is built with debug symbols:
Reading symbols from /home/user/fglrx crash/crashtest-build-desktop-Qt_4_8_1__Qt-4_8_1__Debug/crashtest...done.
(gdb) br main
Breakpoint 1 at 0x804996d: file ../program/main.cpp, line 21.
(gdb) run
Starting program: /home/user/fglrx crash/crashtest-build-desktop-Qt_4_8_1__Qt-4_8_1__Debug/crashtest [Thread debugging using libthread_db enabled]
Breakpoint 1, main (argc=1, argv=0xbffff2a4) at ../program/main.cpp:21
21 QApplication a(argc, argv);
(gdb) bt
#0 main (argc=1, argv=0xbffff2a4) at ../program/main.cpp:21
(gdb) n
[New Thread 0xb7d2bb70 (LWP 2475)]
[New Thread 0xb752ab70 (LWP 2476)]
22 QMainWindow w;
(gdb) bt
#0 main (argc=1, argv=0xbffff2a4) at ../program/main.cpp:22
(gdb) s
QFlags<Qt::WindowType>::QFlags (this=0xbffff164) at /usr/local/Trolltech/Qt-4.8.1/include/QtCore/qglobal.h:2284
2284 Q_DECL_CONSTEXPR inline QFlags(Zero = 0) : i(0) {}
(gdb) bt
#0 QFlags<Qt::WindowType>::QFlags (this=0xbffff164) at /usr/local/Trolltech/Qt-4.8.1/include/QtCore/qglobal.h:2284
#1 0x080499a4 in main (argc=1, argv=0xbffff2a4) at ../program/main.cpp:22
You have to generate debug symbols for your own binary as well. Compile your application with GCC's -g option. It's also advisable to turn off optimization for the time of debugging; use GCC's -O0 flag for this purpose.
The simple and awful answer is you can't. According to Graham Sellers of AMD, the driver is compiled with the -fomit-frame-pointer flag, which confuses gdb if it's deeper down the stack.
I'm trying to use the reverse debugging features of gdb 7.3.1 on a multi-threaded project (using libevent), but I get the following error:
(gdb) reverse-step
Target multi-thread does not support this command.
From this question, I thought perhaps that it was an issue loading libthread_db but, when I run the program, gdb says:
Starting program: /home/robb/slug/slug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
How can I enable reverse debugging with gdb 7.3.1 on a multi-threaded project? Is it possible?
To do this, you need to activate the instruction-recording target, by executing the command
record
from the point where you want to go forward and backward (remember that the recording will significantly slow down the execution, especially if you have several threads!)
I've just checked that it's working correctly:
(gdb) info threads
Id Target Id Frame
2 Thread 0x7ffff7860700 (LWP 5503) "a.out" hello (arg=0x601030) at test2.c:16
* 1 Thread 0x7ffff7fca700 (LWP 5502) "a.out" main (argc=2, argv=0x7fffffffe2e8) at test2.c:47
...
(gdb) next
49 p[i].id=i;
(gdb) reverse-next
47 for (i=0; i<n; i++)
...
17 printf("Hello from node %d\n", p->id);
(gdb) next
Hello from node 1
18 return (NULL);
(gdb) reverse-next
17 printf("Hello from node %d\n", p->id);
Im building a shared library on linux. the library ".so" was sucessfully created, but when I tried to link it to a test application (with an empty main) and run the executable I got a segmentation error : "Segmentation error (cure dumped)"
when I tried to debug it with gdb and check the backtrace I got this output:
Program received signal SIGSEGV, Segmentation fault.
0x0073d5df in std::_Rb_tree_decrement(std::_Rb_tree_node_base*) () from /usr/lib/libstdc++.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12.1-4.i686 libgcc-4.4.5-2.fc13.i686 libstdc++-4.4.5-2.fc13.i686 zlib-1.2.3-23.fc12.i686
(gdb) backtrace
#0 0x0073d5df in std::_Rb_tree_decrement(std::_Rb_tree_node_base*) () from /usr/lib/libstdc++.so.6
#1 0x0012d70c in ?? () from /opt/cuda/lib/libcudart.so.3
#2 0x0012df0c in ?? () from /opt/cuda/lib/libcudart.so.3
#3 0x0012c88a in ?? () from /opt/cuda/lib/libcudart.so.3
#4 0x00121435 in __cudaRegisterFatBinary () from /opt/cuda/lib/libcudart.so.3
#5 0x005d7bfd in __sti____cudaRegisterAll_55_tmpxft_00000fe6_00000000_26_MonteCarloPaeo_SM10_cpp1_ii_3a8af011()
() from libsharedCUFP.so
#6 0x005db40d in __do_global_ctors_aux () from libsharedCUFP.so
#7 0x005a8748 in _init () from libsharedCUFP.so
#8 0x008abd00 in _dl_init_internal () from /lib/ld-linux.so.2
#9 0x0089d88f in _dl_start_user () from /lib/ld-linux.so.2
Im not familiar with gdb debugging, and it's the first time Im trying to build a shared library on Linux, but it seems to me that it has something to do with the library dynamic linking.
If anyone had any idea about this error and could help me, I would be grateful.
It doesn't have anything to do with dynamic linking or shared libraries - one of the constructors in libsharedCUFP.so (I assume this is your shared library) is most probably passing an illegal address to a function in libcudart.so which crashes.
You simply need to debug your code.
This is on a Redhat EL5 machine w/ a 2.6.18-164.2.1.el5 x86_64 kernel using gcc 4.1.2 and gdb 7.0.
When I run my application with gdb and break in while it's running, several of my threads show the following call stack when I do a backtrace:
#0 0x000000000051d7da in pthread_cond_wait ()
#1 0x0000000100000000 in ?? ()
#2 0x0000000000c1c3b0 in ?? ()
#3 0x0000000000c1c448 in ?? ()
#4 0x00000000000007dd in ?? ()
#5 0x000000000051d630 in ?? ()
#6 0x00007fffffffdc90 in ?? ()
#7 0x000000003b1ae84b in ?? ()
#8 0x00007fffffffdd50 in ?? ()
#9 0x0000000000000000 in ?? ()
Is this a symptom of a common problem?
Is there a known issue with viewing the call stack while waiting on a condition?
The problem is that pthread_cond_wait is written in hand-coded assembly, and apparently doesn't have proper unwind descriptor (required on x86_64 to unwind the stack) in your build of glibc. This problem may have recently been fixed here.
You can try to build and install the latest glibc (note: if you screw up installation, your machine will likely become unbootable; approach with extreme caution!), or just live with "bogus" stack traces from pthread_cond_wait.
Generally, synchronization is required when multiple threads share a single resource.
In such a case, when you interrupt the program, you'll see only 1 thread is running (i.e., accessing the resource) and other threads are waiting within pthread_cond_wait().
So I don't think pthread_cond_wait() itself is problematic.
If your program hangs with deadlock or performance doesn't scale, it might be caused by pthread_cond_wait().
That looks like a corrupt stack trace to me
for example:
#9 0x0000000000000000 in ?? ()
There shouldn't be code at NULL