Bug 49794 – [Qt] Strange infinite recursion on MiniBrowser termination

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit2

[Balazs Kelemen]

1. go to www.yahoo.com (or any site that requires plugins)
2. close MiniBrowser
I could not find the right moment when to close the browser to be able to reproduce the bug all the time, but sometimes it appears.
Backtrace:
#0  0xb3cf19e7 in ?? () from /lib/libc.so.6
#1  0xb3cf40ba in malloc () from /lib/libc.so.6
#2  0xb3ee9525 in operator new(unsigned int) () from /usr/lib/libstdc++.so.6
#3  0xb3fe2dd6 in QMutex::QMutex (this=0xaba11a88, mode=QMutex::NonRecursive) at thread/qmutex.cpp:124
#4  0xb3fe58bb in QThreadPrivate::QThreadPrivate (this=0xaba11a38, d=0xaba11918) at thread/qthread.cpp:177
#5  0xb3fe5ada in QAdoptedThread::QAdoptedThread (this=0xaba11a28, data=0xaba11918) at thread/qthread.cpp:137
#6  0xb3fe7f29 in QThreadData::current () at thread/qthread_unix.cpp:164
#7  0xb41007e7 in QObject::QObject (this=0xaba117d0, dd=..., parent=0x0) at kernel/qobject.cpp:772
#8  0xb3fe4e60 in QThread::QThread (this=0xaba117d0, dd=..., parent=0x0) at thread/qthread.cpp:385
#9  0xb3fe5aee in QAdoptedThread::QAdoptedThread (this=0xaba117d0, data=0xaba116c0) at thread/qthread.cpp:137
#10 0xb3fe7f29 in QThreadData::current () at thread/qthread_unix.cpp:164
#11 0xb41007e7 in QObject::QObject (this=0xaba11578, dd=..., parent=0x0) at kernel/qobject.cpp:772
#12 0xb3fe4e60 in QThread::QThread (this=0xaba11578, dd=..., parent=0x0) at thread/qthread.cpp:385
#13 0xb3fe5aee in QAdoptedThread::QAdoptedThread (this=0xaba11578, data=0xaba11468) at thread/qthread.cpp:137
#14 0xb3fe7f29 in QThreadData::current () at thread/qthread_unix.cpp:164
#15 0xb41007e7 in QObject::QObject (this=0xaba11320, dd=..., parent=0x0) at kernel/qobject.cpp:772
#16 0xb3fe4e60 in QThread::QThread (this=0xaba11320, dd=..., parent=0x0) at thread/qthread.cpp:385
#17 0xb3fe5aee in QAdoptedThread::QAdoptedThread (this=0xaba11320, data=0xaba11210) at thread/qthread.cpp:137
#18 0xb3fe7f29 in QThreadData::current () at thread/qthread_unix.cpp:164
#19 0xb41007e7 in QObject::QObject (this=0xaba110c8, dd=..., parent=0x0) at kernel/qobject.cpp:772
...
The call stack contains a few thousand items!

By putting a break in QThreadPrivate::start you can catch the top of the call stack:
#4  0xb3fe5aee in QAdoptedThread::QAdoptedThread (this=0x8056168, data=0x8068d88) at thread/qthread.cpp:137
#5  0xb3fe7f29 in QThreadData::current () at thread/qthread_unix.cpp:164
#6  0xb41007e7 in QObject::QObject (this=0x8056018, dd=..., parent=0x0) at kernel/qobject.cpp:772
#7  0xb3fe4e60 in QThread::QThread (this=0x8056018, dd=..., parent=0x0) at thread/qthread.cpp:385
#8  0xb3fe5aee in QAdoptedThread::QAdoptedThread (this=0x8056018, data=0x8058c18) at thread/qthread.cpp:137
#9  0xb3fe7f29 in QThreadData::current () at thread/qthread_unix.cpp:164
#10 0xb41007e7 in QObject::QObject (this=0x8136be8, dd=..., parent=0x0) at kernel/qobject.cpp:772
#11 0xb3fe4e60 in QThread::QThread (this=0x8136be8, dd=..., parent=0x0) at thread/qthread.cpp:385
#12 0xb3fe5aee in QAdoptedThread::QAdoptedThread (this=0x8136be8, data=0x8157cd8) at thread/qthread.cpp:137
#13 0xb3fe7f29 in QThreadData::current () at thread/qthread_unix.cpp:164
#14 0xb411d5cf in postEventSourcePrepare (s=0x815a618, timeout=0x0) at kernel/qeventdispatcher_glib.cpp:254
#15 0xb411d639 in postEventSourceCheck (source=0x815a618) at kernel/qeventdispatcher_glib.cpp:270
#16 0xb350b392 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#17 0xb350bac0 in ?? () from /usr/lib/libglib-2.0.so.0
#18 0xb350bebe in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#19 0xb411d0a1 in QEventDispatcherGlib::processEvents (this=0x815a728, flags=...) at kernel/qeventdispatcher_glib.cpp:415
#20 0xb40ec62a in QEventLoop::processEvents (this=0xb1ffe32c, flags=...) at kernel/qeventloop.cpp:149
#21 0xb40ecab2 in QEventLoop::exec (this=0xb1ffe32c, flags=...) at kernel/qeventloop.cpp:201
#22 0xb3fe530a in QThread::exec (this=0xb283dfd8) at thread/qthread.cpp:490
#23 0xb3fe53cd in QThread::run (this=0xb283dfd8) at thread/qthread.cpp:555
#24 0xb3fe89b9 in QThreadPrivate::start (arg=0xb283dfd8) at thread/qthread_unix.cpp:266
#25 0xb3f256e5 in start_thread () from /lib/libpthread.so.0
#26 0xb3f25600 in ?? () from /lib/libpthread.so.0

[Balazs Kelemen]

I think the bug is related to plugins that fork. Currently we have no full
plugin support, but in PluginInfoStoreQt.cpp we load the plugin to ask it
about it's capabilities. I found in the debugger that we actually do not unload 
the plugin from the UI process (after calling unload for the PluginPackage we
use, I still see the library through "info shared"). Moreover, there are plugins
that fork from NP_Initialize. Seems like Qt tries to do something nasty with
the forked process?

[Balazs Kelemen]

Cannot reproduce anymore.