Re: XView bug/PPC machines available for developers?
> > Apply the following patch
> >
> > --- lib/libxview/attr/attr.c.org Sun Sep 24 22:22:04 2000
> > +++ lib/libxview/attr/attr.c Sun Sep 24 22:21:34 2000
> > @@ -93,7 +93,11 @@
> > */
> > #if (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 1)
> > __va_copy(valist, valist1);
> > +#if defined(__powerpc__)
> > + avlist = avlist1;
> > +#else
> > __va_copy(avlist, avlist1);
> > +#endif
> > #else
> > valist = valist1;
> > avlist = avlist1;
> >
> > and it just works (for me, YMMV, yadda).
> >
> > Sample packages in ftp.biophys.uni-duesseldorf.de:/pub/linux/powerpc/
>
> Huh? Your mileage WILL vary. That defeats the entire point of using
> __va_copy(). avlist1 is, I assume, a va_list; a va_list is an array
> type, and so *avlist1 means avlist1[0], which does not dereference an
> uninitialized pointer. This patch is wrong.
avlist is _not_ a va_list. Please look up the definition of avlist in
lib/libxview/attr/attr.h yourself. avlist is a pointer to some u32 chunk
of data, either a pointer to a avlist attribute or value IIRC.
As such, __va_copy just so happens to work for other archs by accident.
I am well aware of the nature of PPC va_list, and I've had trouble with
this specific type before. Same symptoms: doing bad things with va_lists
results in segfaults.
I'd like to hear from anybody who still gets segfaults from libxview,
maybe we can establish just how much YMMV.
> A FAQ on this sort of problem has been posted to debian-powerpc about a
> dozen times now, and also to debian-arm, IIRC.
Feel free to point out a URL (searchable Debian ML archives would be nice
to have, sometimes).
Michael
Reply to: