Subsurface crashes on launch in OS Mavericks

Thiago Macieira thiago at macieira.org
Sun Jan 12 08:43:38 UTC 2014


On domingo, 12 de janeiro de 2014 15:45:49, Lubomir I. Ivanov wrote:
> On 12 January 2014 05:24, Thiago Macieira <thiago at macieira.org> wrote:
> > If I disassemble 258628 (0x3f244) bytes from the beginning, I see:
> > __ZN14QDesktopWidgetD1Ev:
> > 000000000003f240        pushq   %rbp
> > 000000000003f241        movq    %rsp, %rbp
> > 000000000003f244        popq    %rbp
> > 000000000003f245        jmpq    __ZN7QWidgetD2Ev
> > 000000000003f24a        nopw    (%rax,%rax)
> 
> this code looks a bit strange, but that's possibly due to gcc -O0.
> 
> while pushing the base pointer on the stack and then storing the stack
> pointer into the base pointer (assuming AT&T syntax) is fine, then
> poping it without modifying the rsp would mean that there are no
> arguments to the class constructor(?). still doesn't seem like an
> issue.
> on the other hand that nopw looks like a jump alignment that GAS does
> which is done with optimization in mind and that contradicts a bit
> with the previous 3 instructions.
> 
> is it possible that this is a bad disassembly or the cause is somewhere
> else?

No, not really. The disassembly looks fine. Yes, it looks like GCC was dumb and 
missed a large optimisation opportunity there. But that doesn't mean it's 
wrong. 

That POP instruction cannot be causing a SIGILL. So it's more likely that I 
found the wrong address.

PS: GCC probably generated the prologue, the body of the constructor that just 
needs to reset the virtual pointers, then epilogue, then optimised the body 
out. Here's what the same function does on my 4.7.2 LTO build:

0000003231706a40 <_ZN14QDesktopWidgetD1Ev>:
  3231706a40:   mov    0x4403a9(%rip),%rax        # 3231b46df0 
<_DYNAMIC+0x1558>
  3231706a47:   lea    0x10(%rax),%rdx
  3231706a4b:   add    $0x1d0,%rax
  3231706a51:   mov    %rdx,(%rdi)
  3231706a54:   mov    %rax,0x10(%rdi)
  3231706a58:   jmpq   3231702120 <_ZN7QWidgetD1Ev>
  3231706a5d:   nopl   (%rax)

Here, GCC optimised the prologue and epilogue out, but left the virtual table 
update.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140112/96059a1d/attachment.sig>


More information about the subsurface mailing list