Assertion of ./QtLauncher http://www.google.com: ASSERTION FAILED: !methodCallLinkInfo.cachedStructure (../../../JavaScriptCore/jit/JITPropertyAccess.cpp:642 static void JSC::JIT::patchMethodCallProto(JSC::CodeBlock*, JSC::MethodCallLinkInfo&, JSC::JSFunction*, JSC::Structure*, JSC::JSObject*, JSC::ReturnAddressPtr)) Assertion of ./jsc $WKROOT/SunSpider/tests/sunspider-0.9.1/3d-cube.js ASSERTION FAILED: !callLinkInfo->isLinked() (../../../JavaScriptCore/jit/JIT.cpp:600 static void JSC::JIT::linkCall(JSC::JSFunction*, JSC::CodeBlock*, JSC::CodeBlock*, JSC::JITCode&, JSC::CallLinkInfo*, int, JSC::JSGlobalData*)) I think these are true positive timing related problems. With valgrind both QtLauncher and jsc runs 10-20 times slower then normally, that is why I think about timing.
In interpreter build QtLauncher also crashes when I close the window: Process terminating with default action of signal 11 (SIGSEGV) Access not within mapped region at address 0x4 at 0x76A1277: QObject::thread() const (qobject.cpp:1426) by 0x551F9C0: WebCore::JSDOMWindowBase::commonJSGlobalData() (JSDOMWindowBase.cpp:154) by 0x550B4C0: WebCore::collect(void*) (GCController.cpp:46) by 0x550B531: WebCore::GCController::gcTimerFired(WebCore::Timer<WebCore::GCController>*) (GCController.cpp:69) by 0x550B0E4: WebCore::Timer<WebCore::GCController>::fired() (Timer.h:98) by 0x5AD34A6: WebCore::ThreadTimers::sharedTimerFiredInternal() (ThreadTimers.cpp:112) by 0x5AD36CA: WebCore::ThreadTimers::sharedTimerFired() (ThreadTimers.cpp:90) by 0x5C8DFD1: WebCore::SharedTimerQt::~SharedTimerQt() (SharedTimerQt.cpp:68) by 0x76A181E: QObjectPrivate::deleteChildren() (qobject.cpp:1990) by 0x76A89B8: QObject::~QObject() (qobject.cpp:987) by 0x7694AA9: QCoreApplication::~QCoreApplication() (qcoreapplication.cpp:620) by 0x6C1F3EB: QApplication::~QApplication() (qapplication.cpp:1111)
Please follow the QtWebKit bug reporting guidelines when reporting bugs. See http://trac.webkit.org/wiki/QtWebKitBugs Specifically: - The 'QtWebKit' component should only be used for bugs/features in the public QtWebKit API layer, not to signify that the bug is specific to the Qt port of WebKit http://trac.webkit.org/wiki/QtWebKitBugs#Component - Add the keyword 'Qt' to signal that it's a Qt-related bug http://trac.webkit.org/wiki/QtWebKitBugs#Keywords
(In reply to comment #2) > > - The 'QtWebKit' component should only be used for bugs/features in the > public QtWebKit API layer, not to signify that the bug is specific to > the Qt port of WebKit > > http://trac.webkit.org/wiki/QtWebKitBugs#Component This is not the case so I did not chose the qtwebkit component. > > - Add the keyword 'Qt' to signal that it's a Qt-related bug > > http://trac.webkit.org/wiki/QtWebKitBugs#Keywords I have removed the flag from the bug since I think this is not a qt-specific bug. I think the reason of you can see this crash only inside QtLauncher is that we do a gc just before exiting in debug builds. The problem is gc related.
Bugs relating to the Qt port of WebKit should have the Qt keyword. See http://trac.webkit.org/wiki/QtWebKitBugs
Do we have two different bugs being reported here? It would be nice to split them into two different bug reports. I'm not adding the keyword 'QtTriaged' for now.
The second one (interpreter build crash on app exit) has been solved by r57818. JIT asserts are still happens inside valgrind. I am going to close this one and create a new for those problems. Since the JIT is not very platform specific, I hardly think it is a Qt related bug. (Actually, it is Qt specific because valgrind is used mostly by us :) )
*** This bug has been marked as a duplicate of bug 39060 ***