Closed Aetf closed 8 years ago
This can be a) a permission problem (trying to attach to a process owned by a different user) or b) simply that you ran out of accessible semaphores [1].
For (b), please run ipcs -s
and ipcs -l
on your system. If the output of ipcs -s
is large (> 100 lines), then something is wrong.
[1] https://mail.kdab.com/pipermail/gammaray-commits/2014-March/001114.html
Forgot to mention, GammaRay version used is 2.2.0
Well, for a), I'm the only user on system and use sudo to call GammaRay since normal user can't call ptrace. So no other users other than aetf(my self) and root are involued. No SELinux enabled on system too. I can't think up other possible options that can block such operation.
Actually, I successfully opened GammaRay a few days ago but it crashed quickly with some errors regarding to shared memory.
for b), here are the output
env LC_ALL='c' ipcs -s
------ Semaphore Arrays --------
key semid owner perms nsems
0x51265710 0 aetf 600 1
0x5126480f 458754 root 600 1
env LC_ALL='c' ipcs -l
------ Messages Limits --------
max queues system wide = 15860
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 18014398509465599
max total shared memory (kbytes) = 18014398442373116
min seg size (bytes) = 1
------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767
Ah, I see.
That is the problem already. Using sudo here means: GammaRay will instruct the debuggee (in process) to read out shared memory of the launcher/client owned by root => not allowed.
Not sure what to do about this. Maybe @vkrause has ideas.
Two options for the time being:
gammaray myprog
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
(Further reading: http://askubuntu.com/a/41656)Yes, enable ptrace for normal users solved the problem. But now debuggee crashed as soon as GammaRay attaching to it.
gammaray_probe_inject()
fish: 'build/CLang_x86_64-Debug/neoui/…' terminated by signal SIGSEGV (Address boundary error)
@Aetf: Debug please.
Just run: GAMMARAY_GDB=1 gammaray myprog
, this should give you a GDB prompt in case the debuggee crashes.
The backtrace
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff485a834 in GammaRay::signal_end_callback (caller=0x2b53df0, method_index=3)
at /tmp/workspace/aur-gammaray/src/GammaRay-2.2.0/core/probe.cpp:113
#2 0x00007ffff56e602d in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5
#3 0x00007fffe96a460f in QDBusPendingCallWatcher::finished(QDBusPendingCallWatcher*) () from /usr/lib/libQt5DBus.so.5
#4 0x00007fffe96a5d65 in ?? () from /usr/lib/libQt5DBus.so.5
#5 0x00007ffff56e72da in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#6 0x00007ffff636ef4c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#7 0x00007ffff637436e in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#8 0x00007ffff56b770b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#9 0x00007ffff56b96d3 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#10 0x00007ffff570ed43 in ?? () from /usr/lib/libQt5Core.so.5
#11 0x00007ffff31b3a0d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#12 0x00007ffff31b3cf8 in ?? () from /usr/lib/libglib-2.0.so.0
#13 0x00007ffff31b3dac in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#14 0x00007ffff570f137 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#15 0x00007ffff56b5132 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#16 0x00007ffff56bcaec in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#17 0x0000000000408e12 in main (argc=1, argv=0x7fffffffd9c8) at ../../../neoui/main.cpp:29
(gdb) frame 1
#1 0x00007ffff485a834 in GammaRay::signal_end_callback (caller=0x2b53df0, method_index=3)
at /tmp/workspace/aur-gammaray/src/GammaRay-2.2.0/core/probe.cpp:113
113 method_index = Util::signalIndexToMethodIndex(caller->metaObject(), method_index);
(gdb) l
108 }
109
110 static void signal_end_callback(QObject *caller, int method_index)
111 {
112 #if QT_VERSION >= QT_VERSION_CHECK(5, 0, 0)
113 method_index = Util::signalIndexToMethodIndex(caller->metaObject(), method_index);
114 #endif
115 Probe::executeSignalCallback([=](const QSignalSpyCallbackSet &qt_signal_spy_callback_set) {
116 if (qt_signal_spy_callback_set.signal_end_callback) {
117 qt_signal_spy_callback_set.signal_end_callback(caller, method_index);
(gdb) p method_index
$1 = 3
(gdb) p caller
$2 = (QObject *) 0x2b53df0
The frame #0 should be somewhere in QMetaObjectPrivate::signal(metaObject, signalIndex).methodIndex();
in file core/util.cpp
303 int Util::signalIndexToMethodIndex(const QMetaObject* metaObject, int signalIndex )
304 {
305 #ifdef HAVE_PRIVATE_QT_HEADERS
306 #if QT_VERSION >= QT_VERSION_CHECK(5, 0, 0)
307 return QMetaObjectPrivate::signal(metaObject, signalIndex).methodIndex();
308 #else
So what else should I do now? I'm not really familiar with gdb.
Thanks for the information. That looks like a bug from our side. Nothing more you can do here, unfortunately, we'll have to investigate.
I'm happy to help ;)
Could be deletion of sender() inside the slot connected to QDBusPendingCallWatcher::finisehd(). If that's the case, checking for Probe::isValidObject(caller) should avoid the crash.
@Aetf: So, please try out adding Probe::isValidObject(caller)
to the beginning of signal_end_callback
. Then do another run with GDB attached.
I suppose signal_end_callback
should return immediately if Probe::isValidObject(caller)
returns false? So what to return in this case?
EDIT: I misread the return type.
As I'm further reading the code, another two questions:
Probe::isValidObject(caller)
is not static. Through Probe::instance()
? Probe::instance()
and Probe::isValidObject(caller)
requires locking on Probe::objectLock()
, what type should I lock, read or write?Added this to the beginning of signal_end_callback
:
if (!Probe::objectLock()->tryLockForRead())
return;
if(!Probe::instance()->isValidObject(caller)) {
Probe::objectLock()->unlock();
return;
}
Probe::objectLock()->unlock();
GammaRay opened successfully this time.
However, I can't enter in-process mode either by command line option or using GammaRay launcher. Some pages on the left are still gray and say only available in in-process mode. Not sure if it is related.
The sender deletion issue is fixed in GammaRay to the extend possible now (both in master and 2.2). There's also a bug in Qt though, waiting for integration into 5.4 here: https://codereview.qt-project.org/#/c/104220/
Closing then; see previous comment.
I'm trying to use GammaRay to debug my program but got the following error in the output:
The command used was
The output of uname