whiteknight/io_cleanup1 branch ready for testing

[Nicholas Clark]

On Thu, Aug 16, 2012 at 08:30:35PM -0400, James E Keenan wrote:
> On 8/16/12 12:08 PM, Nicholas Clark wrote:

> > 4294967286 isn't -10. There's a sign extension problem somewhere.
> >
> >
> > Presumably as you're on PPC Darwin you're still on an version of OS X
> > with ktrace and kdump. I guess that they'd show a similar problem with
> > (not) -10
> >
> 
> $> ktrace ./parrot t/pmc/filehandle_28.pir
> $> kdump | tail -100 > tail_t_pmc_filehandle_28_pir_ktrace_dump
> 
> So here (attached) is the last 100 lines of the kdump.  I can send Nick 
> or anyone else who can decipher this the full output.

They contain the useful bit. The file is opened:

>  13352 parrot   CALL  open(0x1108050,0x602,0x1a4)
>  13352 parrot   NAMI  "/tmp/dMWD44zXQv"
>  13352 parrot   RET   open 3

on file descriptor 3.

stuff, which I assume is the buffering layer:

>  13352 parrot   CALL  fstat(0x3,0xbfffeaf4)
>  13352 parrot   RET   fstat 0
>  13352 parrot   CALL  ioctl(0x3,0x4004667a ,0xbfffead8)
>  13352 parrot   RET   ioctl -1 errno 25 Inappropriate ioctl for device
>  13352 parrot   CALL  ioctl(0x3,0x402c7413 ,0xbfffeadc)
>  13352 parrot   RET   ioctl -1 errno 25 Inappropriate ioctl for device

the initial write of 15 bytes from the PIR code:

>  13352 parrot   CALL  write(0x3,0x307f000,0xf)
>  13352 parrot   GIO   fd 3 wrote 15 bytes
>        "abcdefghijklmno"
>  13352 parrot   RET   write 15/0xf

seek back to the beginning:

>  13352 parrot   CALL  lseek(0x3,0,0)
>  13352 parrot   RET   lseek 0

read of (up to) 0x800 bytes:

>  13352 parrot   CALL  read(0x3,0x307e800,0x800)
>  13352 parrot   GIO   fd 3 read 15 bytes
>        "abcdefghijklmno"
>  13352 parrot   RET   read 15/0xf

gets 15 bytes. (But I think that this is the buffering layer trying to read
a full buffer - IIRC the PIR code only wants to read 10 bytes)

And now a seek on file descriptor 3 of 0xfffffff6 bytes from the current
position:

>  13352 parrot   CALL  lseek(0x3,0xfffffff6,0x1)
>  13352 parrot   RET   lseek 1

which works (so far)

Write something to STDOUT:

>  13352 parrot   CALL  write(0x1,0x1106a10,0x3)
>  13352 parrot   GIO   fd 1 wrote 3 bytes
>        "10
>        "
>  13352 parrot   RET   write 3

(Attempt to) write, which will be at the new position:

>  13352 parrot   CALL  write(0x3,0x307f000,0x5)
>  13352 parrot   RET   write -1 errno 28 No space left on device

which fails with the error you reported.


The analogous output from kdump on a 64 bit FreeBSD system looks like this:

 27977 parrot   CALL  lseek(0x3,0,SEEK_SET)
 27977 parrot   RET   lseek 0
 27977 parrot   CALL  read(0x3,0x801b3b800,0x800)
 27977 parrot   GIO   fd 3 read 15 bytes
       "abcdefghijklmno"
 27977 parrot   RET   read 15/0xf
 27977 parrot   CALL  lseek(0x3,0xfffffffffffffff6,SEEK_CUR)
 27977 parrot   RET   lseek 5
 27977 parrot   CALL  write(0x1,0x801b66100,0x3)
 27977 parrot   GIO   fd 1 wrote 3 bytes
       "10
       "
 27977 parrot   RET   write 3
 27977 parrot   CALL  write(0x3,0x801b3c000,0x5)
 27977 parrot   GIO   fd 3 wrote 5 bytes
       "#####"

Note that it's 0xfffffffffffffff6, not 0xfffffff6.
0xfffffff6 when treated as a 64 bit file offset is (about) 4G forwards.
0xfffffffffffffff6 is treated as -10, so 10 bytes backwards.

Nicholas Clark