[Webkit-unassigned] [Bug 159720] [ARM] ASSERTION FAILED: linkBuffer.isValid() in InlineAccess.cpp:291

[bugzilla-daemon at webkit.org]

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

Csaba Osztrogonác <ossy at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ossy at webkit.org

--- Comment #1 from Csaba Osztrogonác <ossy at webkit.org> ---
InlineAccess.cpp
=================
template <typename Function>
ALWAYS_INLINE static bool linkCodeInline(const char* name, CCallHelpers& jit, StructureStubInfo& stubInfo, const Function& function)
{
    if (jit.m_assembler.buffer().codeSize() <= stubInfo.patch.inlineSize) {
        bool needsBranchCompaction = false;
        LinkBuffer linkBuffer(jit, stubInfo.patch.start.dataLocation(), stubInfo.patch.inlineSize, JITCompilationMustSucceed, needsBranc
hCompaction);
        ASSERT(linkBuffer.isValid()); <=================== BANG!
        function(linkBuffer);
        FINALIZE_CODE(linkBuffer, ("InlineAccessType: '%s'", name));
        return true;
    }
...

LinkBuffer.h
=============
bool didFailToAllocate() const
{
    return !m_didAllocate;
}

bool isValid() const
{
    return !didFailToAllocate();
}

====
linkBuffer.isValid() is to ensure that LinkBuffer() constructor 
call sets its m_didAllocate member to true, but it isn't set.

- LinkBuffer::LinkBuffer(...) calls LinkBuffer::linkCode(...)
- LinkBuffer::linkCode(...) calls LinkBuffer::allocate(...)
- LinkBuffer::allocate(...):  initialSize = 12 > m_size = 4
and that's why allocate returns at the beginning without
allocation and setting m_didAllocate to true.

m_code = 0xb27ca808

Dump of assembler code from 0xb27ca808 to 0xb27ca860:
   0xb27ca808:  b       0xb27ca8b0
   0xb27ca80c:  nop                     ; (mov r0, r0)
   0xb27ca810:  nop                     ; (mov r0, r0)
   0xb27ca814:  nop                     ; (mov r0, r0)
   0xb27ca818:  nop                     ; (mov r0, r0)
   0xb27ca81c:  nop                     ; (mov r0, r0)
   0xb27ca820:  nop                     ; (mov r0, r0)
   0xb27ca824:  nop                     ; (mov r0, r0)
   0xb27ca828:  nop                     ; (mov r0, r0)
   0xb27ca82c:  nop                     ; (mov r0, r0)
   0xb27ca830:  nop                     ; (mov r0, r0)
   0xb27ca834:  nop                     ; (mov r0, r0)
   0xb27ca838:  ldr     r0, [r11, #32]
   0xb27ca83c:  ldr     r1, [r11, #36]  ; 0x24
   0xb27ca840:  tst     sp, #15
   0xb27ca844:  beq     0xb27ca850
   0xb27ca848:  mov     r6, #100        ; 0x64
   0xb27ca84c:  bkpt    0x0000
   0xb27ca850:  mov     sp, r11
   0xb27ca854:  pop     {r11}           ; (ldr r11, [sp], #4)
   0xb27ca858:  pop     {lr}            ; (ldr lr, [sp], #4)
   0xb27ca85c:  bx      lr


I think the assertion is simply incorrect in this case and should be removed.
But I don't understand exactly the original change, please let me know
if I misunderstood this bug.

-- 
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/20160714/dc115702/attachment.html>