Mailing List Archive

gzip-1.3.5 cores while building X
Hi People,

Here's my problem: gzip-1.3.5 cores on an Alpha 433au machine
in a rare but repeatable place.

Here are the details -- apologies for the long lines:

When doing an "emerge -ua world", which included x11-base/xorg-x11-6.8.2-r1,
the following error occurred:

LD_LIBRARY_PATH=../../../exports/lib XLOCALEDIR=../../../exports/lib/locale ../../../exports/bin/bdftopcf -t lubR12.bdf | gzip > lubR12.pcf.gz
LD_LIBRARY_PATH=../../../exports/lib XLOCALEDIR=../../../exports/lib/locale ../../../exports/bin/bdftopcf -t lubR14.bdf | gzip > lubR14.pcf.gz
LD_LIBRARY_PATH=../../../exports/lib XLOCALEDIR=../../../exports/lib/locale ../../../exports/bin/bdftopcf -t lubR18.bdf | gzip > lubR18.pcf.gz
LD_LIBRARY_PATH=../../../exports/lib XLOCALEDIR=../../../exports/lib/locale ../../../exports/bin/bdftopcf -t lubR19.bdf | gzip > lubR19.pcf.gz
LD_LIBRARY_PATH=../../../exports/lib XLOCALEDIR=../../../exports/lib/locale ../../../exports/bin/bdftopcf -t lubR24.bdf | gzip > lubR24.pcf.gz
LD_LIBRARY_PATH=../../../exports/lib XLOCALEDIR=../../../exports/lib/locale ../../../exports/bin/bdftopcf -t lutBS08.bdf | gzip > lutBS08.pcf.gz
make[5]: *** [lutBS08.pcf.gz] Error 139
make[5]: Leaving directory `/var/tmp/portage/xorg-x11-6.8.2-r1/work/xc/fonts/bdf/75dpi'
make[4]: *** [all] Error 2
make[4]: Leaving directory `/var/tmp/portage/xorg-x11-6.8.2-r1/work/xc/fonts/bdf'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/var/tmp/portage/xorg-x11-6.8.2-r1/work/xc/fonts'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/var/tmp/portage/xorg-x11-6.8.2-r1/work/xc'
make[1]: *** [World] Error 2

I tried doing this myself, and sure enough...

supper 75dpi # LD_LIBRARY_PATH=../../../exports/lib XLOCALEDIR=../../../exports/lib/locale ../../../exports/bin/bdftopcf -t lutBS08.bdf | gzip > lutBS08.pcf.gz
Segmentation fault (core dumped)

My build flags are normally "-mieee -O3 -mcpu=ev56", so I tried with just "-ggdb3".
No luck.

Examining the core of the unoptimised build shows this:

supper 75dpi # gdb /bin/gzip --core core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "alpha-unknown-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

Core was generated by `gzip'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6.1...done.
Loaded symbols for /lib/libc.so.6.1
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x0000000120002448 in longest_match (cur_match=65486) at deflate.c:468
468 do {
(gdb) list
463 scan += 2, match++;
464
465 /* We check for insufficient lookahead only every 8th comparison;
466 * the 256th check will be made at strstart+258.
467 */
468 do {
469 } while (*++scan == *++match && *++scan == *++match &&
470 *++scan == *++match && *++scan == *++match &&
471 *++scan == *++match && *++scan == *++match &&
472 *++scan == *++match && *++scan == *++match &&
(gdb) p scan
$1 = (uch *) 0x120078000 <Address 0x120078000 out of bounds>
(gdb)

... So this really is a pointer to nowhere.

I happened to have a vanilla gzip-1.2.4a.tar.gz source bundle around, and it
has no problems on the same input file:

supper 75dpi # LD_LIBRARY_PATH=../../../exports/lib XLOCALEDIR=../../../exports/lib/locale ../../../exports/bin/bdftopcf -t lutBS08.bdf | /opt/gzip-1.2.4a/bin/gzip > lutBS08.pcf.gz

This is a puzzling problem, since the build had been running for 228 minutes and
scores of fonts had been gzipped by the time this problem appeared. But I tried
the "emerge -ua world" 3 times, and each time it failed at exactly the same place.
So I don't believe this to be a memory or flaky hardware issue.

The problem also occurs if gzip reads the file directly (i.e. not from stdin):
supper 75dpi # LD_LIBRARY_PATH=../../../exports/lib XLOCALEDIR=../../../exports/lib/locale ../../../exports/bin/bdftopcf -t lutBS08.bdf > lutBS08.pcf
supper 75dpi # gzip lutBS08.pcf
Segmentation fault (core dumped)

Any suggestions?

Andrew.


--
gentoo-alpha@gentoo.org mailing list
Re: gzip-1.3.5 cores while building X [ In reply to ]
Hi Andrew:

Andrew Gaylard wrote:

> Hi People,
>
> Here's my problem: gzip-1.3.5 cores on an Alpha 433au machine
> in a rare but repeatable place.
>
> Here are the details -- apologies for the long lines:
>
> When doing an "emerge -ua world", which included
> x11-base/xorg-x11-6.8.2-r1,
> the following error occurred:
>

There is an open bug [1] about this issue. Yuya Satoh has attached a
patch taken from debian.
Please Andrew, if have enough time, test it and report results on the bug.

Thanks.

--------------------
[1] http://bugs.gentoo.org/show_bug.cgi?id=92232

YosWinK @ gentoo .org
// <mailto:nigoro@gentoo.org>
--
gentoo-alpha@gentoo.org mailing list
Re: gzip-1.3.5 cores while building X [ In reply to ]
Andrew Gaylard wrote:
> Here's my problem: gzip-1.3.5 cores on an Alpha 433au machine
> in a rare but repeatable place.

Ooops, I should have checked bugzilla first, where I would have seen
that this is already a known problem: bug 92232.

(http://bugs.gentoo.org/show_bug.cgi?id=92232)

Sorry for wasting everyone's time.

I see that there's already a patch for this problem.

Any ideas when it'll be possible to emerge a newer gzip?

Andrew

--
gentoo-alpha@gentoo.org mailing list
Re: gzip-1.3.5 cores while building X [ In reply to ]
Jose Luis Rivero wrote:
> Hi Andrew:
>
> Andrew Gaylard wrote:
>> Here's my problem: gzip-1.3.5 cores on an Alpha 433au machine
>> in a rare but repeatable place.
>
> There is an open bug [1] about this issue. Yuya Satoh has attached a
> patch taken from debian.
> Please Andrew, if have enough time, test it and report results on the bug.
>
> Thanks.
>
> --------------------
> [1] http://bugs.gentoo.org/show_bug.cgi?id=92232

I've tested the patch (gzip-1.3.5-alpha.patch), and it fixes it for me.
Interestingly, the patched gzip-1.3.5 produced a different output from that of
the vanilla gzip-1.2.4a (the compressed files were different). Yet they both could
be decompressed by each other's gunzip, and the decompressed files were identical.

So I think this patch is "good-to-go"!

I have also added this comment to the bug directly in bugzilla.

--
Andrew.

(Now, why won't sendmail-8.13.3 build? Hmmmm...)

--
gentoo-alpha@gentoo.org mailing list