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
0x819d4c3 <_ZN5cmELF8GetRPathEv+3>: sub $0x8,%esp
0x819d4c6 <_ZN5cmELF8GetRPathEv+6>: mov 0x8(%ebp),%eax
0x819d4c9 <_ZN5cmELF8GetRPathEv+9>: mov (%eax),%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.
Note that "this" looks like:
(gdb) p *this
$3 = {Internal = 0x0, ErrorMessage = {static npos = 4294967295,
_M_dataplus = {<std::allocator<char>> =
{<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
fields>}, _M_p = 0xa0b402c "Error reading ELF identification."}}}
(edx is indeed 0x0, so that's definitely why it SEGV'd. And eax==this,
so I don't think I'm too far in the bushes guessing what went wrong.)
Note also that I first spotted this in 2.6.0-1.fc10.i386; my .rpm which
I kept around is timestamped 2008-05-06 (it also SEGV'd, but I upgraded
to 2.6.1 before digging into it, so I can't absolutely confirm the same
bug).
Because it looks like the generated code is bad, I'm inclined to blame
this first on the distro (Fedora) but I'm also CC'ing the cmake folk
(though I guess really I should be blaming either gcc, or come to think
of it, possibly gas), and also gcc-help as I figure they're most likely
to be able to make sense of the disassembly. Can anyone shed some light
on this?
I'll likely try to debug this further (please feel free to request
additional information), but for now it's a head's up of a bug in the
Fedora package.
(To the gcc folk: I know it's not a STC*, or even full code; sorry for
that, though in my experience compiler bugs like this disappear as soon
as the code is touched in the slightest manner, plus I don't have direct
access to the machine this was built on anyway. Hopefully I'll be able
to work with the Fedora people on that if it's needed. What I'm mainly
looking for from y'all is a second opinion if the assembly is clearly
whacked, or if there is an obvious flaw in my analysis.)
(*Simple Test Case)
--
Matthew
ENOWIT: .sig file for this machine not set up yet
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
