Opened 12 years ago

Closed 11 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:
Has a Patch: no 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 Changed 12 years ago by bonefish

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:

int
rpl_chown (const char *file, uid_t uid, gid_t gid)
{

  if (gid == (gid_t) -1 || uid == (uid_t) -1)
    {
      struct stat file_stats;


      if (stat (file, &file_stats))
    return -1;

      if (gid == (gid_t) -1)
    gid = file_stats.st_gid;

      if (uid == (uid_t) -1)
    uid = file_stats.st_uid;
    }


# 101 "/home/bonefish/develop/haiku/haiku/src/bin/coreutils/lib/chown.c"


  return chown (file, uid, gid);
}

The compiled object file looks still OK: From the objdump:

Disassembly of section .text:

00000000 <rpl_chown>:
   0:   55                      push   %ebp
   ...
  5d:   e8 fc ff ff ff          call   5e <rpl_chown+0x5e>
  62:   8d 65 a8                lea    -0x58(%ebp),%esp
  65:   5b                      pop    %ebx
  66:   5e                      pop    %esi
  67:   5f                      pop    %edi
  68:   89 ec                   mov    %ebp,%esp
  6a:   5d                      pop    %ebp
  6b:   c3                      ret

And the relocations:

bonefish@graete:~/develop/haiku/haiku/generated-gcc2> readelf --relocs objects/haiku/x86/release/bin/coreutils/lib/chown.o

Relocation section '.rel.text' at offset 0x334 contains 3 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000011  0000070a R_386_GOTPC       00000000   _GLOBAL_OFFSET_TABLE_
00000031  00000804 R_386_PLT32       00000000   stat
0000005e  00000904 R_386_PLT32       00000000   chown

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:

000052ec <rpl_chown>:
    52ec:       55                      push   %ebp
    ...
    5344:       e8 a3 ff ff ff          call   52ec <rpl_chown>
    5349:       8d 65 a8                lea    -0x58(%ebp),%esp
    534c:       5b                      pop    %ebx
    534d:       5e                      pop    %esi
    534e:       89 ec                   mov    %ebp,%esp
    5350:       5d                      pop    %ebp
    5351:       c3                      ret

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.

comment:2 Changed 12 years ago by andreasf

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 Changed 12 years ago by korli

I checked on my side last week, and I confirm what bonefish wrote: the object file is correct, not the linked executable.

comment:4 Changed 12 years ago by korli

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.

comment:5 Changed 11 years ago by korli

Resolution: fixed
Status: newclosed

The fix is OK

Note: See TracTickets for help on using tickets.