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

Bug#249986: marked as done (ld.so crashes by SEGV on custom kernel)

Your message dated Mon, 19 Feb 2007 17:27:25 +0100
with message-id <20070219162721.GA19703@farad.aurel32.net>
and subject line Bug#249986: ld.so crashes by SEGV on custom kernel
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message --- 
Package: libc6
Version: 2.2.5-6

I participate in development some kind of Linux emulator under Windows. We
use Debian as packaging system in our project, because I'm reporting
straighit to you (as glibc guys reccomended). The bug (I beleive its the
bug) we met couldn't be reproduced under usual Linux kernels, so I provide
you with details. When I invoke almost any program, it killed by SEGV:


/windrives/c/devel/projects/pd/release#ls
Segmentation fault


Our own strace-like log is quite informative about this:


[14] execve("/bin/ls", ["ls", "-A", "--color=auto"], 0x080db2d0) {
} = 0
Exception 0xc0000005 (ACCESS_VIOLATION) at address 0x00951658 (read from
0x0000001c)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
     00950000-00963000 r-xp 00000000 00:01 383554 /lib/ld-2.2.5.so
     00963000-00964000 rw-p 00013000 00:01 383554 /lib/ld-2.2.5.so
     08048000-08053000 r-xp 00000000 00:01 383114 /bin/ls
     08053000-08054000 rw-p 0000a000 00:01 383114 /bin/ls
     0fe00000-10000000 rwxp ffffc000 00:00 0


I've done some work and found the bug in $glibc-2.2.5\elf\dynamic-link.h,
_ELF_DYNAMIC_DO_RELOC macro:


struct { ElfW(Addr) start, size; int lazy; } ranges[2]; \

ranges[0].lazy = 0; \

ranges[0].size = ranges[1].size = 0; \

ranges[0].start = 0; \

\



As one can see, `ranges' array is allocated on stack and *not* initialized.
Its ok under native Linux, because just after `execve' system call, process
stack is always cleared and `ranges' always became filled by zeroes. But our
environment can not (should it?) guarantee stack contents, and ranges[1] got
unpredictable values. Well, just few lines later, in conditional branch
where ld combines sections, ranges[1].start and ranges[1].size are crap.

So, I propose to fix _ELF_DYNAMIC_DO_RELOC macro and clear the`ranges'
variable (at least with undefined ELF_MACHINE_PLTREL_OVERLAP macro), since
virtually possible another architecture, where just-after-execve-stack is
not cleared.

PS. If you not interested in this fix, please inform me. Thank you.

--- End Message ---
--- Begin Message --- 
On Sun, May 23, 2004 at 03:20:13AM +0900, GOTO Masanori wrote:
> At Fri, 21 May 2004 10:52:00 +0400,
> Alexander Gordeyev wrote:
> >  GM> You may get the different result with the latest glibc 2.3.2.ds1
> >  GM> instead of 2.2.5 old woody version.
> > 
> > Nope, we can't, since we stuck to stable release. I didn't check it against
> > glibc-2.3.2, but the source from http://ftp.gnu.org/gnu/glibc contains the
> > same bug.
> 
> Unfortunatelly we don't have no plan to modify stable release woody.
> Moreover, the next release sarge is coming to freeze to release, so
> currently we can't change most routines.
> 
> > *** dynamic-link.h Thu Jan 30 20:35:50 2003
> > --- dynamic-link-fixed.h Thu May 20 11:17:26 2004
> > *************** elf_get_dynamic_info (struct link_map *l
> > *** 250,255 ****
> > --- 250,256 ----
> > 
> > {                                                                   \
> >               /* Combine processing the sections.  */
> > \
> >               assert (ranges[0].start + ranges[0].size == start);
> > \
> > +             ranges[1].start = NULL;
> > \
> >               ranges[0].size += (map)->l_info[DT_PLTRELSZ]->d_un.d_val;
> > \
> >             }
> > \
> >         }
> > \
> 
> > There is more important issue. I recall, clearing of stack even by kernel is
> > just pleasant side effect. In fact, it shouldn't (it shouldn't even clear
> > the .bss). And I'm very easy imagine some time-critical architecture with
> > swapping where just allocated pages aren't cleared due to performance
> > issues.
> > 
> > PS. Did I right understand, you refuse this bug?
> 
> Yes, we should not depend on the non-standardized kernel behavior.
> Could you provide more information for this bug why this bug fixes the
> bug...?
> 

We don't support non-standard kernel, and as no more information has
been provided, I am closing the bug.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

--- End Message ---
Reply to: