[Webkit-unassigned] [Bug 161308] REGRESSION (r205107): ASSERTION FAILED: !(reinterpret_cast<char*>(this)[i])

[bugzilla-daemon at webkit.org]

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

--- Comment #10 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to comment #7)
> Ok.
> Third guess, there is now 4 bytes of padding after the ArrayModes
> m_arrayModes
> field, maybe those aren't getting zeroed out? And for some reason, clang
> zeroes
> them out.

It seems that the standard only guarantees that the padding in structures is zero-initialized on some very specific cases [1]. In the rest of cases it is undefined behaviour. And this seems to be one of this cases. That explains why clang is zero-initializing the padding of the structure, but GCC does not.

This fixes the issue with GCC:

--- a/Source/JavaScriptCore/dfg/DFGAbstractValue.h
+++ b/Source/JavaScriptCore/dfg/DFGAbstractValue.h
@@ -191,21 +191,21 @@ struct AbstractValue {

     static AbstractValue heapTop()
     {
-        AbstractValue result;
+        static AbstractValue result;
         result.makeHeapTop();
         return result;
     }

     static AbstractValue bytecodeTop()
     {
-        AbstractValue result;
+        static AbstractValue result;
         result.makeBytecodeTop();
         return result;
     }

     static AbstractValue fullTop()
     {
-        AbstractValue result;
+        static AbstractValue result;
         result.makeFullTop();
         return result;
     }



Now I wonder if this is the best approach (declaring it as static), or it will be better to directly bzero the structure on the constructor, or perhaps it will be better to modify the assert to check only the values of the members of the structure.


[1] https://gustedt.wordpress.com/2012/10/24/c11-defects-initialization-of-padding/

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160831/dae63bd3/attachment.html>