Bug#427395: libc6: df command causes system crash on parisc
John David Anglin a écrit :
>>> fstat64(3, {st_mode=0, st_size=0, ...}) = 0
>>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40005000
>>> read(3, "/dev/sda3 / ext3 rw,errors=remou"..., 4096) = 339
>>> read(3, "", 4096) = 0
>>> close(3) = 0
>>> munmap(0x40005000, 4096) = 0
>>> fstat64(1, {st_mode=0, st_size=4299262263301, ...}) = 0
>>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40005000
>>> write(1, "Filesystem 1K-blocks "..., 67Filesystem 1K-blocks Used Available Use% Mounted on
>>> ) = 67
>>> upeek: ptrace(PTRACE_PEEKUSER,1410,4294967292,0): Input/output error
>> This strace looks "normal" or rather this seems to be a different bug. I
>> mean I have the same output on my machine when running with strace, but
>> df works correctly when not run with strace.
>
> Kyle says "df uses statfs64, which was added to 2.6.21... I'm confused
> why we're not catching it in syscall.S, I'll need to sit and think a bit."
>
>From the glibc code, the statfs64 uses the statfs64 syscall has been
enabled since we switched to 2.6.21 kernel headers (ie in 2.5-7).
It does not uses this syscall unconditionaly. It first tries to do a
statfs64 syscall, and falls back to a statfs one if the return value is
ENOSYS.
It really looks like a bug in the kernel.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: