[Webkit-unassigned] [Bug 199295] Memory corruption when creating JSGlobalContext (valgrind false-positive)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=199295

--- Comment #14 from Michael Catanzaro <mcatanzaro at gnome.org> ---
Here's what it looks like with --track-origins:

==449866== Invalid write of size 8
==449866==    at 0x9F56DCB: ??? (in /home/mcatanzaro/Projects/GNOME/install/lib/libjavascriptcoregtk-4.0.so.18.17.0)
==449866==    by 0xA0CB298: operator() (LocalAllocatorInlines.h:39)
==449866==    by 0xA0CB298: allocate<JSC::LocalAllocator::allocate(JSC::Heap&, JSC::GCDeferralContext*, JSC::AllocationFailureMode)::<lambda()> > (FreeListInlines.h:46)
==449866==    by 0xA0CB298: allocate (LocalAllocatorInlines.h:37)
==449866==    by 0xA0CB298: allocate (AllocatorInlines.h:35)
==449866==    by 0xA0CB298: allocateNonVirtual (IsoSubspaceInlines.h:34)
==449866==    by 0xA0CB298: tryAllocateCellHelper<JSC::ArrayPrototype> (JSCellInlines.h:163)
==449866==    by 0xA0CB298: allocateCell<JSC::ArrayPrototype> (JSCellInlines.h:177)
==449866==    by 0xA0CB298: JSC::ArrayPrototype::create(JSC::VM&, JSC::JSGlobalObject*, JSC::Structure*) (ArrayPrototype.cpp:72)
==449866==    by 0xA1D0CA2: JSC::JSGlobalObject::init(JSC::VM&) (JSGlobalObject.cpp:703)
==449866==    by 0xA1D78E8: JSC::JSGlobalObject::finishCreation(JSC::VM&) (JSGlobalObject.cpp:2144)
==449866==    by 0x96DE09D: create (JSAPIGlobalObject.h:51)
==449866==    by 0x96DE09D: JSGlobalContextCreateInGroup (JSContextRef.cpp:143)
==449866==    by 0x967E901: jscContextSetVirtualMachine(_JSCContext*, WTF::GRefPtr<_JSCVirtualMachine>&&) (JSCContext.cpp:107)
==449866==    by 0x9681DEE: jscContextConstructed(_GObject*) (JSCContext.cpp:153)
==449866==    by 0x53C25F5: g_object_new_internal (gobject.c:1867)
==449866==    by 0x53C3B04: g_object_new_with_properties (gobject.c:1995)
==449866==    by 0x53C46B0: g_object_new (gobject.c:1667)
==449866==    by 0x967EF29: jsc_context_new (JSCContext.cpp:596)
==449866==    by 0x6974F54: getOrCreateContext (WebKitJavascriptResultPrivate.h:44)
==449866==    by 0x6974F54: _WebKitJavascriptResult (WebKitJavascriptResult.cpp:31)
==449866==    by 0x6974F54: webkitJavascriptResultCreate(WebCore::SerializedScriptValue&) (WebKitJavascriptResult.cpp:45)
==449866==  Address 0x1ffeffdb68 is on thread 1's stack
==449866==  464 bytes below stack pointer

So, I know the stack grows down, and therefore this shouldn't be causing any harm because the zeroed memory should not be used by any current stack frame.

That said: valgrind spam like this makes it impractical to debug serious memory safety problems and detect actual security bugs, so we need to avoid triggering this warning somehow. And valgrind suppressions are not an OK answer; nobody ever uses those.

Does JSC *really* need to write below the stack pointer? When did we start doing this? (Early last year? The warnings did not occur before last year.) Ideally we would stay within our own stack frame and not trigger a spam of serious-looking warnings like this. It's seriously weird....

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200319/510a20dc/attachment.htm>