Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes: > Now it works. Congratulations! > 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. > 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). > 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? > 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? > This is a big chance for you (yes, YOU) /me looks behind himself > to actually get the hand dirty with a debugger and debug some > *interesting* Hurd translator bugs. I tried to debug pfinet last week, but gdb failed pretty quickly with something like "couldn't fetch registers from thread". What's this supposed to mean? -- Robbe
Attachment:
signature.ng
Description: PGP signature