[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.)

`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

Reply to: