Bug 34484 – [Qt] QtLauncher and jsc ASSERTS when run with valgrind

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: JavaScriptCore

[Balazs Kelemen]

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.

[Balazs Kelemen]

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)

[Tor Arne Vestbø]

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

[Balazs Kelemen]

(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.

[Tor Arne Vestbø]

Bugs relating to the Qt port of WebKit should have the Qt keyword. See http://trac.webkit.org/wiki/QtWebKitBugs

[Jesus Sanchez-Palencia]

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.

[Balazs Kelemen]

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 :) )

[Balazs Kelemen]

*** This bug has been marked as a duplicate of bug 39060 ***