Re: compiler issues and some booboos
Eric Delaunay <delaunay@lix.polytechnique.fr> writes:
> I already filed a bug against util-linux 2.9w. Wait next upload...
Groovy!
> > 2. grep is failing with messages like:
> >
> > grep: guile-core_1.3.4-0.diff.gz: Bad address
> > grep: guile-core_1.3.4-0.dsc: Bad address
> > grep: guile-core_1.3.4-0_sparc.changes: Bad address
> > grep: guile-core_1.3.4.orig.tar.gz: Bad address
> > grep: guile1.3_1.3.4-0_sparc.deb: Bad address
> > grep: libguile6-dev_1.3.4-0_sparc.deb: Bad address
> > grep: libguile6-slib_1.3.4-0_sparc.deb: Bad address
> > grep: libguile6_1.3.4-0_sparc.deb: Bad address
> >
> > making grep useless. I tried recompiling from source but it made no
> > difference at all.
>
> Until I installed grep 2.3-5 from potato I got the same errors.
> However it was fixed in this version, maybe only on old sparc ? In fact, I'm
> running Debian on a SparcClassic.
I'm on an ultra1, and the problem persists with grep 2.3-7. Some
debuggery shows that it's a call to read that is failing, inside the
fillbuf function in grep.c on line 337 or so. "Bad Address" is the
string representation of EFAULT, so I figure it's got to by the second
argument to read that is faulty. That is a buffer and a offset which
is derived somewhere in what the source calls the "hairy buffering
mechanism for grep" cause it tries to make sure all reads on page
boundaries and for multiple of page sizes.
i'm wagering something in the hairy mechanism isn't liking the
sparc64s that much. I'm not good enough yet to track it down, but I'm
good enough to submit a bug.
--
Craig Brozefsky <craig@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
"riot shields. voodoo economics. its just business. cattle
prods and the IMF." - Radiohead, OK Computer, Electioneering
Reply to: