Opened 17 years ago
Closed 17 years ago
#1776 closed bug (fixed)
chown crashes
Reported by: | andreasf | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Applications/Command Line Tools | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
chown baron test
crashes with a segmentation fault in _lstat
.
The backtrace has a long list of rpl_chown
(more than one page), and above lstat
and _lstat
(both from libroot.so).
Change History (5)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
Are you sure the compiled object file is okay? Doesn't it already have the recursion by call
'ing rpl_chown
rather than chown
?
comment:3 by , 17 years ago
I checked on my side last week, and I confirm what bonefish wrote: the object file is correct, not the linked executable.
comment:4 by , 17 years ago
It seems coreutils provides a lchown replacement which happens to be named rpl_chown as the chown wrapper. To avoid this, we don't include the lchown replacement in hrev24053.
The crash is caused by an infinite recursion in rpl_chown(), i.e. it calls itself, although it actually shouldn't. The preprocessed source looks OK:
The compiled object file looks still OK: From the objdump:
And the relocations:
So the address for the call is supposed to be relocated to chown. In the linked executable the function doesn't look good anymore, though:
The address has been replaced with that of rpl_chown, for no reason I can see. Link map and cross reference table don't show any irregularities.
--trace-symbol=chown
lists libroot.so as the only place of definition.I can reproduce this with binutils 2.17, 2.17.50 (Linux), 2.15, and 2.9. I can't really believe that this is a long-standing bug in ld, but I don't have any other explanation ATM.