Close task when using qt-launchpad

[Norman Feske]

Hello,

thanks for reporting. For reproducing the issue, a few more details
would help:

Which base platform (kernel) are you using?

Are you using Qt4 or Qt5?

What happens after the message occurred? Does qt_launchpad stop working
or is the message merely triggered by the process that is being killed
anyway? In the latter case, this message is actually not a problem. It
might be a side effect of killing the process. However, if qt_launchpad
gets stuck, we have a hit a bug.

>     I used qt-launchpad to start tasks, sometimes when I close a task
> ,this error occur
> 
>     Possible null pointer READ at 0 IP 54796d
> 
>     Has everyone met this error before ?How can I fix it?

I would first try to reproduce the problem on base-linux. On Linux, I
expect that the symptom will be different, i.e., the program will raise
a segmentation fault. You can see a corresponding message in the dmesg
output. If you can successfully reproduce the problem on Linux, attach
GDB to the qt_launchpad process, and start end kill a process until the
problem occurs. Now, you should see a nice backtrace in GDB.

If the problem cannot be reproduced on Linux, we'd need to investigate
differently. Looking at the instruction pointer (IP), the offending code
seems to reside in the dynamic linker (ld.lib.so). You can use objdump
to take a closer look at the surrounding code:

  objdump -lSd <genode-build-dir>/bin/ld.lib.so | less

In the 'less' utility, search for the IP value that was printed in the
message.

If the problem can be reproduced on base-foc, you have another debugging
option using the kernel debugger. You can identify the crashed thread by
looking at the "present list" ('lp' command). The crashed thread will
have a pending page-fault message to the pager thread. That is, in the
"wait" column, you will see the ID of the pager thread. Once you know
the thread ID, you can get a backtrace using the 'btt' command. Look up
the corresponding code of the printed instruction pointers in the
objdump output to get an idea what the thread was attempting to do. You
will possibly see IP values in two or more different ranges, each range
corresponding to either the dynamic linker, the actual executable, or a
shared library. You can use binutil's 'readelf' utility to find out the
address ranges of the text segments of the former two. For shared
libraries, however, the location of the text segment is not known prior
runtime.

If the problem can be reproduced on either base-nova or base-foc, you
can use Genode's GDB monitor. You can learn more about this option here:

  http://genode.org/documentation/developer-resources/gdb

Best regards
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth