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