2006-11-13 20:53:31

by Anton Vorontsov

[permalink] [raw]
Subject: Re: [ARM] Corrupted .got section with 2.6.18 and JFFS2 (solved)

Hello Richard, Enrico!

On Fri, Nov 03, 2006 at 11:09:35AM +0100, Enrico Scholz wrote:
> [CC lkml; original issue at
> http://article.gmane.org/gmane.linux.ports.arm.kernel/28068]
>
> [email protected] (Richard Purdie) writes:
>
> >> > I have a problem with JFFS2 filesystem and kernel 2.6.18. When
> >> > starting a program which uses a certain library (libutil.so.1 in
> >> > my case), the .got section of the library can be initialized
> >> > wrongly when the used memory is uninitialized.
> >>
> >> Problem seems to be caused by
> >>
> >> | [PATCH] zlib_inflate: Upgrade library code to a recent version
> >>
> >> (4f3865fb57a04db7cca068fed1c15badc064a302)
> >>
> >> After reverting this (and related patches), things seem to work.
> >>
> >> I don't have an idea yet, which changes in this complex patch are
> >> really responsible....
> >
> > I'm the author of the above change. I just ran your test program
> > on a device (ARM PXA255 with 2.6.19-rc4 kernel, 2.3.5ish glibc,
> > gcc 3.4.4, libraries on jffs2) and I can't reproduce the
> > problem.
>
> I can reproduce it 100% with:

Same here. I can reproduce exactly same problem. And reverting zlib
changes fixes it. I'm testing it on ARM PXA270 + binutils-2.17 +
glibc-2.5 + gcc-4.1.1 (old ABI).

> > Which other related patches did you remove?
>
> For 2.6.18 tests, I reverted only the patches which changed
> lib/zlib_* after 2.6.17:
>
> | 31925c8857ba17c11129b766a980ff7c87780301 [PATCH] Fix ppc32 zImage inflate
> | b762450e84e20a179ee5993b065caaad99a65fbf [PATCH] zlib inflate: fix function definitions
> | 0ecbf4b5fc38479ba29149455d56c11a23b131c0 move acknowledgment for Mark Adler to CREDITS
> | 4f3865fb57a04db7cca068fed1c15badc064a302 [PATCH] zlib_inflate: Upgrade library code to a recent version

Indeed. Reverting these patches fixes all these pesky issues with
jffs2/libutil/openpty.

> Enrico

Thanks,

-- Anton (irc: bd2)

2006-11-14 21:13:03

by Anton Vorontsov

[permalink] [raw]
Subject: Re: [ARM] Corrupted .got section with 2.6.18 and JFFS2 (solved)

Hi all,

On Fri, Nov 03, 2006 at 11:09:35AM +0100, Enrico Scholz wrote:
> [CC lkml; original issue at
> http://article.gmane.org/gmane.linux.ports.arm.kernel/28068]
>
> [email protected] (Richard Purdie) writes:
>
> >> > I have a problem with JFFS2 filesystem and kernel 2.6.18. When
> >> > starting a program which uses a certain library (libutil.so.1 in
> >> > my case), the .got section of the library can be initialized
> >> > wrongly when the used memory is uninitialized.
> >>
> >> Problem seems to be caused by
> >>
> >> | [PATCH] zlib_inflate: Upgrade library code to a recent version
> >>
> >> (4f3865fb57a04db7cca068fed1c15badc064a302)
> >>
> >> After reverting this (and related patches), things seem to work.
> >>
> >> I don't have an idea yet, which changes in this complex patch are
> >> really responsible....
> >
> > I'm the author of the above change. I just ran your test program
> > on a device (ARM PXA255 with 2.6.19-rc4 kernel, 2.3.5ish glibc,
> > gcc 3.4.4, libraries on jffs2) and I can't reproduce the
> > problem.
>
> I can reproduce it 100% with:

As I told before (but it's not delivered to the arm-linux-kernel), I
can reproduce it too, using glibc-2.4 or glibc-2.5. I can't reproduce
it using glibc-2.3.5.

My further investigations shows that reading libutil.so.1
(cat /lib/libutil.so.1 > /dev/null) prior using it eliminates
segfault. That, I suppose, means that glibc can easily operate on
cached file, but refuses to initially ""read"" it from disk properly.

Quoting Richard Purdie:

"The file is read ok from the disk when copying and when read with
md5sum. I therefore wonder if the dynamic linker is doing something it
shouldn't."

Though, it may be either glibc or JFFS2 issue. As for glibc, it's not
using read() call as do cat, cp or md5sum, glibc using readonly
mmap call (which is supported by JFFS2 if I understood code correctly)
on libraries ld-linux wants to load.


I hope these itinerary of mine will bring some light on that issue, and
someone will guess where real bug is. ;-)

>
> Enrico

-- Anton (irc: bd2)