https://bugs.documentfoundation.org/show_bug.cgi?id=173585
--- Comment #22 from Neil Roberts <[email protected]> --- I stepped through the disassembly of SwXTextRanges::Create with lldb. Near the top of the function there is this: 0x18242cc96 <+38>: movl $0x80, %edi 0x18242cc9b <+43>: callq 0x18292d1e0 ; symbol stub for: rtl_allocateMemory 0x18242cca0 <+48>: movq %rax, %r15 0x18242cca3 <+51>: movq %rax, %rbx I think that is allocating the 128 bytes of memory for the SwXTextRangesImpl object. A pointer to this gets stored in %rbx. I think the constructor and MakeRanges are then inlined into same function. So then later on there is this, which I think is the top of MakeRanges: 0x18242ce58 <+488>: movq 0x70(%rbx), %r12 0x18242ce5c <+492>: movq (%r12), %rax This is accessing the end of the SwXTextRangesImpl object, which is the sw::UnoCursorPointer member. As you can see, it extracts the pointer and then just immediately dereferences it. It looks like the check for !GetCursor() at the top of MakeRanges is being optimised out. GetCursor is just “return &(*m_pUnoCursor)”, where the operator* implementation for m_pUnoCursor returns a reference. So I think this is relying on undefined behaviour when m_pUnoCursor is null, because dereferencing nullptr is undefined. Presumably whatever version of the compiler is used to make release builds on MacOS is taking advantage of this to optimise away the if-statement. The proposed fix is here: https://gerrit.libreoffice.org/c/core/+/211318 -- You are receiving this mail because: You are the assignee for the bug.
