Re: Bug#60807: fgetpos() fails on read only filesystems
> Where do those "<filename>: Read-only file system" come from? Is this an
> auto display of some sort? I couldn't determine it from the script you sent.
> If it is an auto display, it seems to imply that errno is EROFS before/when
> entering fgetpos, and not changed while executing it. This could mean that
> fgetpos runs correctly, and the errno value is bogus. However, why would
> fgetpos return a value != 0?
>
It is an internal display; when restoring my Hurd (dpkg-hurd), I got an fgetpos
fail from dpkg. Had to make the partition read/write first.
Not got much spare time, right now. Stepping though the procedures fgetpos,
fgets, __stdio_check_offset, __stdio_seek; the failure is in __io_seek. Have not
had time to check which procedure in __io_seek is setting OutP-> RetCode, maybe
next week.
Script started on Mon Apr 24 10:10:40 2000
cal@hurd:~$ export LD_LIBRARY_PATH=/lib/debug
cal@hurd:~$ gdb marcus
GNU gdb 19990928
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-gnu0.2"...
(gdb) b 22
Breakpoint 1 at 0x80486c3: file marcus.c, line 22.
(gdb) run /Debs/Marcus
Starting program: /home/cal/marcus /Debs/Marcus
[Switching to thread 66.3]
[Switching to thread 66.4]
Breakpoint 1, main (argc=2, argv=0x1019ba0) at marcus.c:22
22 Result = fgetpos(f, &fpos);
(gdb) b __stdio_check_internals
**** Slight modification, with int Result added in.
Breakpoint 3, __stdio_check_offset (stream=0x80499e8) at internals.c:116
116 if ((*stream->__io_funcs.__seek) (stream->__cookie,
Breakpoint 5, __io_seek (io_object=91, offset=0, whence=1, newp=0x1019aa8)
at /Source/glibc-2.1.3/i386-gnu/obj/hurd/RPC_io_seek.c:73
**** This is where we get failure for read only file systems
Breakpoint 12, __io_seek (io_object=91, offset=0, whence=1, newp=0x1019aa8)
at /Source/glibc-2.1.3/i386-gnu/obj/hurd/RPC_io_seek.c:168
168 if (OutP->RetCode != KERN_SUCCESS)
**** The stream in much the same for read only, or read/write systems.
1: *stream = {__magic = -19218709, __bufp = 0x804ba49 "",
__get_limit = 0x804ba48 "T", __put_limit = 0x804ba48 "T",
__buffer = 0x804ba48 "T", __bufsize = 512, __cookie = 0x101ef88, __mode = {
__read = 0, __write = 1, __append = 0, __binary = 0, __create = 0,
__exclusive = 0, __truncate = 0}, __io_funcs = {
__read = 0x1092450 <__stdio_read>, __write = 0x1092594 <__stdio_write>,
__seek = 0x1092708 <__stdio_seek>, __close = 0x1092f10 <__stdio_close>,
__fileno = 0x1093390 <__stdio_fileno>}, __room_funcs = {
__input = 0x1091f8c <fillbuf>, __output = 0x1091c80 <flushbuf>},
__offset = -1, __target = -1, __next = 0x80498e0, __pushback_bufp = 0x0,
__pushback = 0 '\000', __pushed_back = 0, __eof = 0, __error = 0,
__userbuf = 0, __linebuf = 1, __linebuf_active = 1, __seen = 1,
__ispipe = 0, __lock = 0x0}
**** This test always fails for read only
Breakpoint 3, __io_seek (io_object=91, offset=0, whence=1, newp=0x1019aa8)
at /Source/glibc-2.1.3/i386-gnu/obj/hurd/RPC_io_seek.c:168
168 if (OutP->RetCode != KERN_SUCCESS)
(gdb) display OutP->RetCode
1: OutP->RetCode = 1073741854
(gdb) step
0x1174c49 173 return MIG_TYPE_ERROR;
1: OutP->RetCode = 1073741854
**** Here is the trace.
(gdb) bt
#0 0x1174c49 in __io_seek (io_object=91, offset=0, whence=1, newp=0x1019aa8)
at /Source/glibc-2.1.3/i386-gnu/obj/hurd/RPC_io_seek.c:173
#1 0x1092b71 in __stdio_seek (cookie=0x101ee48, pos=0x1019aa8, whence=1)
at ../sysdeps/mach/hurd/sysd-stdio.c:111
#2 0x1091a6d in __stdio_check_offset (stream=0x80499e8) at internals.c:116
#3 0x108ec21 in ftell (stream=0x80499e8) at ftell.c:36
#4 0x108ed1e in fgetpos (stream=0x80499e8, pos=0x1019b34) at fgetpos.c:37
#5 0x80486d3 in main (argc=2, argv=0x1019ba0) at marcus.c:22
(gdb)
**** This is the same thing using a read/write file system. The test is a
success.
Breakpoint 3, __io_seek (io_object=91, offset=0, whence=1, newp=0x1019aa8)
at /Source/glibc-2.1.3/i386-gnu/obj/hurd/RPC_io_seek.c:168
168 if (OutP->RetCode != KERN_SUCCESS)
(gdb) cont
Continuing.
Breakpoint 4, __io_seek (io_object=91, offset=0, whence=1, newp=0x1019aa8)
at /Source/glibc-2.1.3/i386-gnu/obj/hurd/RPC_io_seek.c:172
172 if (* (int *) &OutP->newpType != * (int *) &newpCheck)
(gdb) cont
Continuing.
fetch inferior registers: 4: Invalid thread
fetch inferior registers: 4: Invalid thread
Hope this helps
Chris
PS
I think there may be a further bug down the line. When I run settrans /Debs,
in single user mode, then reboot, this partition is no longer available.
But during boot up, and every boot from then on I still see
/dev/hd1s2: clean, 13178/253952 files, 471754/1013985 blocks
fsck and friends are still looking at the partition
Reply to: