Can't attach to process on Archlinux

[Aetf]

I'm trying to use GammaRay to debug my program but got the following error in the output:

QML debugging is enabled. Only use this in a safe environment.
gammaray_probe_inject()
Unable to receive probe settings, cannot attach to shared memory region "gammaray-11789" "/tmp/qipc_sharedmemory_gammaraybf7a476e31c6719face2851d5851f1587a54c4b5" , error is: "QSharedMemoryPrivate::initKey: unable to set key on lock"
Continueing anyway, with default settings.
Unable to receive probe settings, cannot attach to shared memory region "gammaray-11789" "/tmp/qipc_sharedmemory_gammaraybf7a476e31c6719face2851d5851f1587a54c4b5" , error is: "QSharedMemoryPrivate::initKey: unable to set key on lock"
Continueing anyway, with default settings.

The command used was

sudo gammaray -p 11789 --inprocess

The output of uname

Linux Aetf-Arch-Laptop 3.17.4-1-ARCH #1 SMP PREEMPT Fri Nov 21 21:14:42 CET 2014 x86_64 GNU/Linux

[krf]

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

[Aetf]

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

[krf]

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:

• Start the program right away with gammaray: gammaray myprog
• Enable ptrace for normal users: echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope (Further reading: http://askubuntu.com/a/41656)

[Aetf]

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)

[krf]

@Aetf: Debug please.

Just run: GAMMARAY_GDB=1 gammaray myprog, this should give you a GDB prompt in case the debuggee crashes.

[Aetf]

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.

[krf]

Thanks for the information. That looks like a bug from our side. Nothing more you can do here, unfortunately, we'll have to investigate.

[Aetf]

I'm happy to help ;)

[vkrause]

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.

[krf]

@Aetf: So, please try out adding Probe::isValidObject(caller) to the beginning of signal_end_callback. Then do another run with GDB attached.

[Aetf]

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.

[Aetf]

As I'm further reading the code, another two questions:

• How do I get a Probe instance since Probe::isValidObject(caller) is not static. Through Probe::instance() ?
• According to the comments in header file, both Probe::instance() and Probe::isValidObject(caller) requires locking on Probe::objectLock(), what type should I lock, read or write?

[Aetf]

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.

[vkrause]

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/

[krf]

Closing then; see previous comment.