CODEWITHSUNDEEP
pythonpython-3.xqtdebugginggdb
Kajsa
Kajsa

Reputation: 251

How to read gdb output

I am writing a program in Python 3.5 and using PyQt4 for all GUI functions. When I run the program I, sometimes, get a segmentation fault. I looked online for solutions and found this, which uses gdb.

I tried running my program this way but have no idea how to read the output. Could anyone please give me a hint?

Output:

gdb python3
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python3...(no debugging symbols found)...done.
(gdb) run GUI3.py 
Starting program: /usr/bin/python3 GUI3.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff3ad0700 (LWP 26031)]
[New Thread 0x7ffff12cf700 (LWP 26032)]
[New Thread 0x7fffeeace700 (LWP 26033)]
[New Thread 0x7fffd3da2700 (LWP 26034)]
[New Thread 0x7fffd2042700 (LWP 26035)]
[New Thread 0x7fffd1841700 (LWP 26036)]
[New Thread 0x7fffd1040700 (LWP 26037)]
[New Thread 0x7fffbb952700 (LWP 26038)]
Run function needs to be implemented

Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
QWidgetBackingStore::sync (this=0x1ec5d30) at painting/qbackingstore.cpp:1239
1239    painting/qbackingstore.cpp: No such file or directory.
(gdb) backtrace 
#0  QWidgetBackingStore::sync (this=0x1ec5d30) at painting/qbackingstore.cpp:1239
#1  0x00007fffe0e11c50 in QWidgetPrivate::syncBackingStore (this=0x1907c20)
at kernel/qwidget.cpp:1894
#2  0x00007fffe0e249b8 in QWidget::event (this=this@entry=0x1b3b380, event=event@entry=0x20bab70)
at kernel/qwidget.cpp:8693
#3  0x00007fffe12089b3 in QMainWindow::event (this=0x1b3b380, event=0x20bab70)
at widgets/qmainwindow.cpp:1478
#4  0x00007fffe1cfc28b in ?? ()
   from /usr/lib/python3/dist-packages/PyQt4/QtGui.cpython-35m-x86_64-linux-gnu.so
#5  0x00007fffe0dcdfdc in QApplicationPrivate::notify_helper (this=this@entry=0x18f9d70, 
receiver=receiver@entry=0x1b3b380, e=e@entry=0x20bab70) at kernel/qapplication.cpp:4570
#6  0x00007fffe0dd4f16 in QApplication::notify (this=0x17de970, receiver=0x1b3b380, e=0x20bab70)
at kernel/qapplication.cpp:4356
#7  0x00007fffe1ebc0c6 in ?? ()
   from /usr/lib/python3/dist-packages/PyQt4/QtGui.cpython-35m-x86_64-linux-gnu.so
#8  0x00007fffe2eb390d in QCoreApplication::notifyInternal (this=0x17de970, 
receiver=receiver@entry=0x1b3b380, event=event@entry=0x20bab70)
at kernel/qcoreapplication.cpp:955
#9  0x00007fffe2eb73c6 in QCoreApplication::sendEvent (event=0x20bab70, receiver=0x1b3b380)
at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231
#10 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, 
event_type=event_type@entry=0, data=0x18fc490) at kernel/qcoreapplication.cpp:1579
#11 0x00007fffe2eb76a3 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, 
event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1472
#12 0x00007fffe2ee413e in QCoreApplication::sendPostedEvents ()
at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:236
#13 postEventSourceDispatch (s=0x1900aa0) at kernel/qeventdispatcher_glib.cpp:300
#14 0x00007fffe2a62197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007fffe2a623f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007fffe2a6249c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007fffe2ee42ae in QEventDispatcherGlib::processEvents (this=0x17be390, flags=...)
at kernel/qeventdispatcher_glib.cpp:450
#18 0x00007fffe0e7b616 in QGuiEventDispatcherGlib::processEvents (this=<optimised out>, flags=...)
at kernel/qguieventdispatcher_glib.cpp:204
#19 0x00007fffe2eb218f in QEventLoop::processEvents (this=this@entry=0x7fffffffd7d0, flags=...)
at kernel/qeventloop.cpp:149
#20 0x00007fffe2eb24f5 in QEventLoop::exec (this=this@entry=0x7fffffffd7d0, flags=...)
at kernel/qeventloop.cpp:204
#21 0x00007fffe2eb84b9 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1227
#22 0x00007fffe1e6aa2b in ?? ()
    from /usr/lib/python3/dist-packages/PyQt4/QtGui.cpython-35m-x86_64-linux-gnu.so
#23 0x00000000004e9b7f in PyCFunction_Call ()
#24 0x00000000005372f4 in PyEval_EvalFrameEx ()
#25 0x0000000000540199 in ?? ()
#26 0x0000000000540e4f in PyEval_EvalCode ()
#27 0x000000000060c272 in ?? ()
#28 0x000000000060e71a in PyRun_FileExFlags ()
#29 0x000000000060ef0c in PyRun_SimpleFileExFlags ()
#30 0x000000000063fb26 in Py_Main ()
#31 0x00000000004cfeb1 in main ()
(gdb)

Upvotes: 1

Views: 1538

Answers (2)

ks1322
ks1322

Reputation: 35716

Could anyone please give me a hint?

When you see crash in third party code like libQtGui.so in this case, it is worth to google top part of stack trace in the hope to find the relevant already reported bug where you can probably find workaround or version number to update to.

In this case googling QWidgetPrivate::syncBackingStore leads to this bug https://bugreports.qt.io/browse/QTBUG-41428 which is duplicate of another bug https://bugreports.qt.io/browse/QTBUG-41108. Though it was reported for Mac OS, it may be relevant to x86_64-linux-gnu as well.

Upvotes: 1

einpoklum
einpoklum

Reputation: 131546

Well, a hint: What you're seeing is the call stack.

As you surely know being a programmer, calling a function (or a method) involves adding that call's context (arguments, local variables, return address) to the area in memory called the stack.

So, you're seeing the calls that your code (and code that's not yours) made - and that had not yet returned - when the segmentation fault happened. As your process got the segfault, it didn't continue executing or "unwind" the stack - it just dumped all of the frames. (And note the frames are listed from deepest to shallowest.)

Luckily for you, most of the stack frames have the name of the function running, so you can better figure out where exactly you accessed memory in a problematic segment. Unfortunately for you, the stack trace doesn't seem to have line numbers (those are all the pairs of ??s), so you can't really pinpoint it except to the calls to the function that constitutes the next stack frame in. Also unfortunately for you - it looks like most/all of those names are in-built functions of PyQT or of QT or of just Python, rather than your own functions (though I might be wrong here, especially if you've overloaded) - and this also makes it more difficult for you to figure out where you've caused these segfaults - since you've probably set some values which later case the code that's not yours to make invalid accesses.

Upvotes: 2

Related Questions