Subsurface crashes on launch in OS Mavericks

[Thiago Macieira]

On domingo, 12 de janeiro de 2014 07:42:40, Linus Torvalds wrote:
> On Jan 12, 2014 6:55 AM, "Dirk Hohndel" <dirk at hohndel.org> wrote:
> > can you also send the output of "uname -a"
> > (just making sure you Core 2 Duo is indeed running in 64bit mode as it
> > should)
> 
> You can tell from the register dump that it's in 64-bit mode, so that part
> should be fine.
> 
> It looks (again, from the registers) like it crashed in marble. Weren't
> there problems with alternate installations of marble being found first on
> OSX?

There were: if the person had built Marble locally, its plugins might be found 
by Subsurface but they might be incompatible.

But I don't see that in the backtrace. It looks like it crashed before main, 
in a global initialiser in QtGui. The RIP register has value 
0x0000000101f78244, which places it in QtGui:

       0x101f39000 -        0x102798ff7 +QtGui (4.8.5)
<C79B33C7-A7FB-38B6-A0FA-C5D62F1A3018>
/Applications/Subsurface.app/Contents/Frameworks/QtGui.framework/Versions/4/QtGui

And the backtrace:
Thread
0 Crashed:: Dispatch queue: com.apple.main-thread
0   QtGui                                0x0000000101f78244 0x101f39000 + 
258628

It's close enough to the beginning of QtGui to be in the text section: 

$ otool -l QtGui
QtGui:
Load command 0
      cmd LC_SEGMENT_64
  cmdsize 1032
  segname __TEXT
   vmaddr 0x0000000000000000
   vmsize 0x0000000000934000
  fileoff 0
 filesize 9650176
  maxprot 0x00000007
 initprot 0x00000005
   nsects 12
    flags 0x0
Section
  sectname __text
   segname __TEXT
      addr 0x0000000000004d00
      size 0x0000000000658bf8
    offset 19712
     align 2^4 (16)
    reloff 0
    nreloc 0
     flags 0x80000400
 reserved1 0
 reserved2 0

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)

I don't see how that 1-byte instruction can cause a SIGILL, especially since 
there's a push two instructions below that didn't cause a problem.

It's possible that I didn't locate the correct instruction. Which begs the 
question: what kind of crash reporter shows a SIGILL but doesn't include the 
bytes close to RIP?

-- 
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/20140111/19df481a/attachment.sig>