Re: XFree86 4.0.1 works!
On Tue, Oct 24, 2000 at 01:35:08PM +0200, Robert Bihlmeyer wrote:
> > 1. pflocal gets a load of threads (about 1700 after a couple of minutes
> > using X). This doesn't seem to be harmful though.
>
> I'm seeing something along this lines without X, too. pflocal grows
> without bounds, and takes over the machine. See my "facourite crashes"
> message.
Yes, but that's a different one :) The number of threads doesn't grow after
X is exited. Well, not until the bug you describes occurs also. :)
> > 3. xdm deletes LD_LIBRARY_PATH from the environment, which means that
> > it can't start other X processes. Setting the following in
> > /etc/X11/xdm-config works around that, but might be a security risk(?):
> > DisplayManager.exportList: LD_LIBRARY_PATH
>
> A bigger problem IMHO is that xterm is setuid, and setuid binaries
> should obviously ignore LD_LIBRARY_PATH. Therefore, normal users can't
> execute xterm (nor xvt).
Is this so? I always run as root :) Seriously, we will have to take a look
at those "run X as a normal user" issues anyway, but after I updated the
glibc package (which contains a linker fix to avoid crashes with setuid
binaries and LD_LIBRARY_PATH).
> > Could also be fixed with rpath, which conflicts with Debian
> > policy.
>
> What kind of philosophical reasoning prevents the hurd loader from
> using /etc/ld.so.conf?
That's a question I can't answer. The last answer I got was that "rpath is
the right thing for this problem", and the last comment I got from a Debian
developer on this (representing the majority) was "nothing overrides rpath
so its evil". OTOH, the first person wrote the linker while Debian sort-of
abused ld.so for the glibc transition (not bumping the soname number,
but special casing the libc version in the linker). So it's even :)
> > 4. kbd translator returns Interrupted System Call at open(). I can't
> > reproduce this seperate from the Xserver, so this is a weird problem.
> > Trying several times usually leads to success.
>
> Hmm, is EINTR more common on the hurd? I remember having to restart
> apt a few times on bigger downloads because it fails with "interrupted
> system call in select()". Under most unices, one can pretty much rely
> on EINTR not happening, as long as one uses SA_RESTART in one's signal
> handling. Is that different on the hurd?
Not at all. SA_RESTART is the default, maye there is a bug. Check if apt
does something special which might break the default.
> > This is a big chance for you (yes, YOU)
>
> /me looks behind himself
Shocked to see 600 people there, right? ;)
(I am envisioning some of Mordillos cartoons with dozens of animals staring
at you. Or the southpark cows.)
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: