Messages in this thread | | | From | (Chris Adams) | Subject | Re: OSF/1 binaries on linux/axp bug (fs/exec.c) | Date | 22 Oct 1998 10:28:30 -0500 |
| |
Once upon a time, Bob McElrath <mcelrath@draal.physics.wisc.edu> said: >The linux/axp implementation of loading OSF/1 binaries seems to have a bug. >The loading works fine, but generates the following message: > > 513:/sbin/loader: Fatal Error: loader cannot be invoked directly > >After perusing fs/exec.c I beleve the reason to be that /sbin/loader gets >run twice, once for the original application, and a second time >*for*itself*. ps reveals: > >(0)<mcelrath@draal:/home/mcelrath> netscape & >[1] 512 >513:/sbin/loader: Fatal Error: loader cannot be invoked directly >(0)<mcelrath@draal:/home/mcelrath> ps aux | grep loader >mcelrath 512 0.6 6.5 22920 16688 ? S 11:48 0:01 /sbin/loader >mcelrath 513 0.0 0.0 0 0 ? Z 11:48 0:00 (loader <zombie>) > >Thus, I surmise that /sbin/loader is executed a *second* time, with itself >as its argument, and subsequently fails and gives the above message. > >Can someone more familiar with the data structures involved in loading and >executing binaries possibly look at this and eliminate the second execution >of /sbin/loader? I can test any patches that anyone comes up with.
The second execute is because netscape re-executes itself to get asynchronous DNS lookups. The standard resolver libraries only support synchronous DNS lookups, so to allow the user to interrupt them, netscape starts a second process it can signal. I suspect the problem lies in the fact that the ARGV string shows /sbin/loader instead of netscape, so when netscape looks at its ARGV to find its own name and run it, it instead tries to run /sbin/loader, which doesn't work.
I never tried to figure out how to fix it - I just turned off async DNS lookups (put "export MOZILLA_NO_ASYNC_DNS=True" in your .profile to do this). -- Chris Adams - cadams@ro.com System Administrator - Renaissance Internet Services I don't speak for anybody but myself - that's enough trouble.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |