Hi,
on an NFS mounted fs, executing as root I see this:
[root@sirizidl nfsr]# ll /nfsr/toplev.fig
-rw------- 1 kernel users 48500 Oct 5 11:42 /nfsr/toplev.fig
[root@sirizidl nfsr]# xfig /nfsr/toplev.fig
[snip]
...
stat64("toplev.fig", {st_mode=S_IFREG|0600, st_size=48500, ...}) = 0
open("toplev.fig", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0600, st_size=48500, ...}) = 0
old_mmap(NULL, 48500, PROT_READ, MAP_PRIVATE, 4, 0) = 0xc0011000
read(4, 0xefffe4cb, 1) = -1 EIO (Input/output error)
_llseek(4, 48500, [48500], SEEK_SET) = 0
--- SIGBUS (Bus error) ---
glibc crashes in fgets because it doesn't expect the problem after the
file has been successfully opened and mapped.. who is at fault here?
Remote nfs server is an old userspace implementation btw.
Richard
On Sat, 2002-10-05 at 16:50, Trond Myklebust wrote:
> >>>>> " " == Richard Zidlicky <[email protected]> writes:
>
> > Hi, on an NFS mounted fs, executing as root I see this:
>
> > read(4, 0xefffe4cb, 1) = -1 EIO (Input/output error)
>
> > glibc crashes in fgets because it doesn't expect the problem
> > after the file has been successfully opened and mapped.. who is
> > at fault here?
>
> The 'soft' mount option perhaps?
If glibc crashes because of an unmap you are I suspect running a gcc 2.3
snapshot with the buggy and bogus mmap stdio option. If so turn it off
before it does any more harm.
>>>>> " " == Richard Zidlicky <[email protected]> writes:
> Hi, on an NFS mounted fs, executing as root I see this:
> read(4, 0xefffe4cb, 1) = -1 EIO (Input/output error)
> glibc crashes in fgets because it doesn't expect the problem
> after the file has been successfully opened and mapped.. who is
> at fault here?
The 'soft' mount option perhaps?
Cheers,
Trond
On Sat, Oct 05, 2002 at 05:07:33PM +0100, Alan Cox wrote:
> On Sat, 2002-10-05 at 16:50, Trond Myklebust wrote:
> > >>>>> " " == Richard Zidlicky <[email protected]> writes:
> >
> > > Hi, on an NFS mounted fs, executing as root I see this:
> >
> > > read(4, 0xefffe4cb, 1) = -1 EIO (Input/output error)
> >
> > > glibc crashes in fgets because it doesn't expect the problem
> > > after the file has been successfully opened and mapped.. who is
> > > at fault here?
> >
> > The 'soft' mount option perhaps?
no, automount entry is
nfsr -rw,noatime rz:/usr/m68kroot
> If glibc crashes because of an unmap you are I suspect running a gcc 2.3
> snapshot with the buggy and bogus mmap stdio option. If so turn it off
> before it does any more harm.
thanks, this seems to be one part of the solution - it is a glibc snapshot
from rawhide, somewhat aged in the meantime.
I am still surprised that NFS returns such strange error instead of
EACCESS but that is probably bad interaction with the old NFS server.
Richard
.