Re: compiler bug turning up in cmake package?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matthew Woehlke wrote:
> I'm getting this SEGV trying to install kdelibs on my machine (koji
> package 2.6.1-1.fc10.i386):
> 
> #0  cmELF::GetRPath (this=0xbf986708) at
> /usr/src/debug/cmake-2.6.1/Source/cmELF.cxx:787
> #1  0x080e9c07 in cmSystemTools::CheckRPath (file=@0xbf986800,
> newRPath=@0xbf9867fc)
>     at /usr/src/debug/cmake-2.6.1/Source/cmSystemTools.cxx:2617
> #2  0x08134378 in cmFileCommand::HandleRPathCheckCommand
> (this=0x9ad3db8, args=@0xbf986874)
>     at /usr/src/debug/cmake-2.6.1/Source/cmFileCommand.cxx:1557
> #3  0x0815dd6a in cmFileCommand::InitialPass (this=0x9ad3db8,
> args=@0xbf986874)
>     at /usr/src/debug/cmake-2.6.1/Source/cmFileCommand.cxx:121
> #4  0x081620cc in cmCommand::InvokeInitialPass (this=0x9ad3db8,
> args=@0x9ad3fd4, status=@0xbf986918)
>     at /usr/src/debug/cmake-2.6.1/Source/cmCommand.h:68
> #5  0x080c65a8 in cmMakefile::ExecuteCommand (this=0x9ac2730,
> lff=@0x9ad3fc8, status=@0xbf986918)
>     at /usr/src/debug/cmake-2.6.1/Source/cmMakefile.cxx:399
> #6  0x08150baa in cmIfFunctionBlocker::IsFunctionBlocked
> (this=0x9ad1170, lff=@0x9ad7f98, mf=@0x9ac2730,
>     inStatus=@0xbf9869f8) at
> /usr/src/debug/cmake-2.6.1/Source/cmIfCommand.cxx:116
> #7  0x080b95dc in cmMakefile::IsFunctionBlocked (this=0x9ac2730,
> lff=@0x9ad7f98, status=@0xbf9869f8)
>     at /usr/src/debug/cmake-2.6.1/Source/cmMakefile.cxx:2303
> 
> The relevant code is pretty boring:
> 
> 785     bool cmELF::Valid() const
> 786     {
> 787       return this->Internal && this->Internal->GetFileType() !=
> FileTypeInvalid;
> 788     }
> 
> ...but the disassembly is unnerving:
> 
> 0x819d4c0 <_ZN5cmELF8GetRPathEv>:       push   %ebp
> 0x819d4c1 <_ZN5cmELF8GetRPathEv+1>:     mov    %esp,%ebp

I think you may be right.

First passed arg is at %ebp + 8.

The stack is:

  this
  retaddr
  prev frame   <--  %ebp

> 0x819d4c3 <_ZN5cmELF8GetRPathEv+3>:     sub    $0x8,%esp
> 0x819d4c6 <_ZN5cmELF8GetRPathEv+6>:     mov    0x8(%ebp),%eax

%eax now contains this

> 0x819d4c9 <_ZN5cmELF8GetRPathEv+9>:     mov    (%eax),%edx

First word of object -> %edx

> 0x819d4cb <_ZN5cmELF8GetRPathEv+11>:    test   %edx,%edx
> 0x819d4cd <_ZN5cmELF8GetRPathEv+13>:    je     0x819d510 <_ZN5cmELF8GetRPathEv+80>
> 0x819d4cf <_ZN5cmELF8GetRPathEv+15>:    mov    0x10(%edx),%eax
> 0x819d4d2 <_ZN5cmELF8GetRPathEv+18>:    test   %eax,%eax
> 0x819d4d4 <_ZN5cmELF8GetRPathEv+20>:    je     0x819d500 <_ZN5cmELF8GetRPathEv+64>
> 0x819d4d6 <_ZN5cmELF8GetRPathEv+22>:    cmp    $0x2,%eax
> 0x819d4d9 <_ZN5cmELF8GetRPathEv+25>:    je     0x819d4e2 <_ZN5cmELF8GetRPathEv+34>
> 0x819d4db <_ZN5cmELF8GetRPathEv+27>:    cmp    $0x3,%eax
> 0x819d4de <_ZN5cmELF8GetRPathEv+30>:    xchg   %ax,%ax
> 0x819d4e0 <_ZN5cmELF8GetRPathEv+32>:    jne    0x819d500 <_ZN5cmELF8GetRPathEv+64>
> 0x819d4e2 <_ZN5cmELF8GetRPathEv+34>:    mov    (%edx),%eax
> 0x819d4e4 <_ZN5cmELF8GetRPathEv+36>:    movl   $0xf,0x4(%esp)
> 0x819d4ec <_ZN5cmELF8GetRPathEv+44>:    mov    %edx,(%esp)
> 0x819d4ef <_ZN5cmELF8GetRPathEv+47>:    call   *0x14(%eax)
> 0x819d4f2 <_ZN5cmELF8GetRPathEv+50>:    leave
> 0x819d4f3 <_ZN5cmELF8GetRPathEv+51>:    nop
> 0x819d4f4 <_ZN5cmELF8GetRPathEv+52>:    lea    0x0(%esi,%eiz,1),%esi
> 0x819d4f8 <_ZN5cmELF8GetRPathEv+56>:    ret
> 0x819d4f9 <_ZN5cmELF8GetRPathEv+57>:    lea    0x0(%esi,%eiz,1),%esi
> 0x819d500 <_ZN5cmELF8GetRPathEv+64>:    xor    %eax,%eax
> 0x819d502 <_ZN5cmELF8GetRPathEv+66>:    leave
> 0x819d503 <_ZN5cmELF8GetRPathEv+67>:    nop
> 0x819d504 <_ZN5cmELF8GetRPathEv+68>:    lea    0x0(%esi,%eiz,1),%esi
> 0x819d508 <_ZN5cmELF8GetRPathEv+72>:    ret
> 0x819d509 <_ZN5cmELF8GetRPathEv+73>:    lea    0x0(%esi,%eiz,1),%esi
> 0x819d510 <_ZN5cmELF8GetRPathEv+80>:    mov    0x10(%edx),%eax
> 0x819d513 <_ZN5cmELF8GetRPathEv+83>:    nop
> 0x819d514 <_ZN5cmELF8GetRPathEv+84>:    lea    0x0(%esi,%eiz,1),%esi
> 0x819d518 <_ZN5cmELF8GetRPathEv+88>:    jmp    0x819d4db
> <_ZN5cmELF8GetRPathEv+27>
> 
> Look particularly at the test at +11 and jump at +13, and then at lines
> +80 and +15. If I read this right, it tests if "this->Internal" is NULL,
> and then *dereferences it either way*. This is clearly not what the
> source listing says (and is clearly wrong), so I wonder where this
> generated code came from.
> 
> Hmm, actually, staring it it, trying to figure out how to hot-hack it so
> the install will finish, it looks like the jump address is wrong (should
> be going to +64, not +80). Or else, something funny is happening w.r.t.
> "Internal"s vtable.

I think you need to press ahead at full speed to generate a standalone
test case from this.

Andrew.

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux