Bug 48840 - Crash from valgrind in javascript garbagecollector
Summary: Crash from valgrind in javascript garbagecollector
Status: RESOLVED DUPLICATE of bug 40875
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Critical
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-02 08:45 PDT by xxx
Modified: 2011-05-17 04:43 PDT (History)
6 users (show)

See Also:


Attachments
test case (86.47 KB, application/x-compressed-tar)
2010-11-08 06:26 PST, xxx
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description xxx 2010-11-02 08:45:22 PDT
I can reproduce the problem on Linux ubuntu 10.4 with WebKit-r70732, only when running with valgrind. I need to run it from valgrind because I run webkit from a Qt application, and we need to ensure the whole software quality.

1) tar zxvf reportBug.tgz
2) valgrind ./Programs/GtkLauncher reportBug/index.html
3) After webkit fully loads the page (see progress percentage in titlebar), a white page will appear. 
4) Click anywhere on the page.
5) A message "Error opening file: No such file or directory" will appear, since I didn't include any image to reduce the attachment size.
6) Sometimes it will already crash here, showing the error description below.
7) If it didn't crash yet, go back to previous page and go to step 4) again.

I tried following valgrind's advice to use "--main-stacksize= ", but even if I increase the value to 100Mb, I always get a crash

thanks

==15225== Process terminating with default action of signal 11 (SIGSEGV)
==15225==  Access not within mapped region at address 0xECACF24
==15225==    at 0x4ED2B19: JSC::JIT::unlinkCallOrConstruct(JSC::CallLinkInfo*) (in /home/dani/tmp/webkit/WebKit-r70732/.libs/libwebkitgtk-1.0.so.0.3.0)
==15225==    by 0x4F3B1DE: JSC::CodeBlock::unlinkCallers() (in /home/dani/tmp/webkit/WebKit-r70732/.libs/libwebkitgtk-1.0.so.0.3.0)
==15225==    by 0x4E550B7: JSC::JSFunction::~JSFunction() (in /home/dani/tmp/webkit/WebKit-r70732/.libs/libwebkitgtk-1.0.so.0.3.0)
==15225==    by 0x4EE99D5: JSC::Heap::sweep() (in /home/dani/tmp/webkit/WebKit-r70732/.libs/libwebkitgtk-1.0.so.0.3.0)
==15225==    by 0x4EED212: JSC::Heap::collectAllGarbage() (in /home/dani/tmp/webkit/WebKit-r70732/.libs/libwebkitgtk-1.0.so.0.3.0)
==15225==    by 0x41BEA03: WebCore::collect(void*) (in /home/dani/tmp/webkit/WebKit-r70732/.libs/libwebkitgtk-1.0.so.0.3.0)
==15225==    by 0x41BEBF0: WebCore::Timer<WebCore::GCController>::fired() (in /home/dani/tmp/webkit/WebKit-r70732/.libs/libwebkitgtk-1.0.so.0.3.0)
==15225==    by 0x4668068: WebCore::ThreadTimers::sharedTimerFiredInternal() (in /home/dani/tmp/webkit/WebKit-r70732/.libs/libwebkitgtk-1.0.so.0.3.0)
==15225==    by 0x46680E4: WebCore::ThreadTimers::sharedTimerFired() (in /home/dani/tmp/webkit/WebKit-r70732/.libs/libwebkitgtk-1.0.so.0.3.0)
==15225==    by 0x48EA02D: WebCore::timeout_cb(void*) (in /home/dani/tmp/webkit/WebKit-r70732/.libs/libwebkitgtk-1.0.so.0.3.0)
==15225==    by 0x590CD5B: ??? (in /lib/libglib-2.0.so.0.2400.1)
==15225==    by 0x590C5E4: g_main_context_dispatch (in /lib/libglib-2.0.so.0.2400.1)
==15225==  If you believe this happened as a result of a stack
==15225==  overflow in your program's main thread (unlikely but
==15225==  possible), you can try to increase the size of the
==15225==  main thread stack using the --main-stacksize= flag.
==15225==  The main thread stack size used in this run was 8388608.

--
Daniel Pinyol
Software Engineer
Pal Robotics S.L.

Tel: +34.93.414.53.47
Fax: +34.93.209.11.09
C/ Pujades 77-79 4º 4ª 08005 Barcelona, Spain.
http://www.pal-robotics.com/

Pablo Picasso - "Computers are useless. They can only give you answers."

AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden contener información privilegiada y/o confidencial que está dirigida exclusivamente a su destinatario. Si usted recibe este mensaje y no es el destinatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notifíquelo inmediatamente y remita el mensaje original a la dirección de correo electrónico indicada. Cualquier copia, uso o distribución no autorizados de esta comunicación queda estrictamente prohibida.

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited.  If you have received this e-mail in error, please immediately notify the sender at the above e-mail address.
Comment 1 Alexey Proskuryakov 2010-11-06 00:02:23 PDT
> 1) tar zxvf reportBug.tgz

Please attach the test case.
Comment 2 xxx 2010-11-08 06:26:33 PST
Created attachment 73236 [details]
test case
Comment 3 Alexey Proskuryakov 2010-11-08 08:49:14 PST
Thanks! What's the role of "_.htaccess" in the archive? Can it be safely ignored?

I don't get any crash when running these steps directly in Safari with r70400 (no valgrind), but this stack trace looks like it may be a genuine cross-platform issue, not just a result of us touching memory valgrind thinks we shouldn't be touching. Geoff, Oliver, what do you think?
Comment 4 xxx 2010-11-08 09:19:00 PST
You can remove the _.htaccess. I also get the crash without it.

Alexey, are you on a Mac? Could you run my page with Mac's valgrind?
Comment 5 Geoffrey Garen 2010-11-08 13:23:26 PST
The stack trace applies to any platform with the JIT enabled.
Comment 6 Alexey Shildyakov 2010-11-19 20:48:44 PST
Think this is duplicate of bug 40875 since that valgrind log contains:

Invalid write of size 8
==22607==    at 0x7A4EA44: JSC::JIT::unlinkCall(JSC::CallLinkInfo*) (X86Assembler.h:1603)
==22607==    by 0x7A94477: JSC::CodeBlock::unlinkCallers() (CodeBlock.cpp:1387)
==22607==    by 0x7B50AFB: JSC::JSFunction::~JSFunction() (JSFunction.cpp:93)
==22607==    by 0x7B3070E: JSC::Heap::sweep() (Collector.cpp:1083)
==22607==    by 0x7B33A9D: JSC::Heap::collectAllGarbage() (Collector.cpp:1279)
==22607==    by 0x73A74B4: WebCore::collect(void*) (GCController.cpp:46)
==22607==    by 0x7718165: WebCore::ThreadTimers::sharedTimerFiredInternal() (ThreadTimers.cpp:112)
==22607==    by 0x79C9C71: WebCore::timeout_cb(void*) (SharedTimerGtk.cpp:48)
==22607==    by 0xA17909A: g_timeout_dispatch (gmain.c:3396)
==22607==    by 0xA1788C1: g_main_context_dispatch (gmain.c:1960)
==22607==    by 0xA17C747: g_main_context_iterate (gmain.c:2591)
==22607==    by 0xA17CC54: g_main_loop_run (gmain.c:2799)
==22607==    by 0x8765B26: gtk_main (gtkmain.c:1219)
==22607==    by 0x435422: main (ephy-main.c:741)
==22607==  Address 0x1fd44f16 is not stack'd, malloc'd or (recently) free'd
==22607== 
==22607== 
==22607== Process terminating with default action of signal 11 (SIGSEGV)
==22607==  Access not within mapped region at address 0x1FD44F16
==22607==    at 0x7A4EA44: JSC::JIT::unlinkCall(JSC::CallLinkInfo*) (X86Assembler.h:1603)
==22607==    by 0x7A94477: JSC::CodeBlock::unlinkCallers() (CodeBlock.cpp:1387)
==22607==    by 0x7B50AFB: JSC::JSFunction::~JSFunction() (JSFunction.cpp:93)
==22607==    by 0x7B3070E: JSC::Heap::sweep() (Collector.cpp:1083)
==22607==    by 0x7B33A9D: JSC::Heap::collectAllGarbage() (Collector.cpp:1279)
==22607==    by 0x73A74B4: WebCore::collect(void*) (GCController.cpp:46)
==22607==    by 0x7718165: WebCore::ThreadTimers::sharedTimerFiredInternal() (ThreadTimers.cpp:112)
==22607==    by 0x79C9C71: WebCore::timeout_cb(void*) (SharedTimerGtk.cpp:48)
==22607==    by 0xA17909A: g_timeout_dispatch (gmain.c:3396)
==22607==    by 0xA1788C1: g_main_context_dispatch (gmain.c:1960)
==22607==    by 0xA17C747: g_main_context_iterate (gmain.c:2591)
==22607==    by 0xA17CC54: g_main_loop_run (gmain.c:2799)
==22607==    by 0x8765B26: gtk_main (gtkmain.c:1219)
==22607==    by 0x435422: main (ephy-main.c:741)


And maybe to resolve this just use valgrind --smc-check=all option as described in bug 39060
Comment 7 Xan Lopez 2011-05-17 04:43:34 PDT
It is a dup. JSC can't run in valgrind without that option atm.

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