Suresh Gopalakrishnan wrote:
>
> On Sun, 16 Dec 2001, Keith Owens wrote:
> > On Sat, 15 Dec 2001 21:24:52 -0500 (EST),
> > Suresh Gopalakrishnan <gsuresh@xxxxxxxxxxxxxx> wrote:
> > >open("/tmp/blah", O_RDWR|O_CREAT|O_DIRECT, 0) = 3
> > >write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> > >8192) = -1
> > > EINVAL (Invalid argument)
> > >fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 7), ...}) = 0
> > >mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> > >= 0x40
> > >018000
> > >ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
> > >write(1, "write returns -1\n", 17write returns -1
> > >) = 17
> > >write(3, "\0", 1) = -1 EFBIG (File too large)
> > >--- SIGXFSZ (File size limit exceeded) ---
> > >+++ killed by SIGXFSZ +++
> >
> > This is a side effect of omitting the create mode on open. It picks
> > up garbage from stack instead of the mode, in this run it picked up
> > mode 0, no access at all. Something in the kernel is trapping write
> > to a file opened with no access and returning EFBIG, which glibc
> > converts to SIGXFSZ. Use a valid mode on open with O_CREAT.
> > Otherwise you pick up stack garbage which can vary from one compile to
> > another.
>
> Hmm.. With 0777 mode argument, it just creates a huge file with the
> appropriate permissions (after umask).. same errors.. :(
>
> -rwxr-xr-x 1 gsuresh users 4294967274 Dec 15 22:14 /tmp/blah
>
> --suresh
Interesting number, hex it is 0xFFFFFFEA. Hex 0x15 off from nice round
power of 2 minus 1, 0xF from turning over a 32 bit number. Not really
helpful, but I would expect in most cases it would be a number exactly
2^x - 1. Where do the last 0x15 bytes go? Is that some kind of overhead
granularity?
D. Stimits, stimits@xxxxxxxxxx (currently bored)
|