r.thin is segfaulting on large files because of a bad type in a couple
of lseeks.
grass61.cvs/raster/r.thin/io.c
lines 71 and 77 read
lseek(file,(long) row * buf_len,0);
but should be
lseek(file, ((off_t)row) * buf_len,0);
can some make the change in CVS?
Thanks,
-Andy
On Wed, 2005-09-07 at 19:31 -0400, Andrew Danner wrote:
r.thin is segfaulting on large files because of a bad type in a couple
of lseeks.grass61.cvs/raster/r.thin/io.c
lines 71 and 77 read
lseek(file,(long) row * buf_len,0);
but should be
lseek(file, ((off_t)row) * buf_len,0);
can some make the change in CVS?
Done, but I really don't see it helping.
What happens if a map exceeds a number of rows greater than the max of
type int?
Does it exit gracefully, or is it a disaster waiting to happen?
lib/rowio is not designed to handle very large rows, AFAICT.
PS -
Take my words lightly. My ammonia levels are in the triple digits of
late and I am not thinking clearly.
--
Brad Douglas <rez@touchofmadness.com>
Thanks for the quick commit. Yes, I suppose if you have more than
MAX_INT rows, bad things will happen, but with MAX_INT being over a
billion (sizeof(int)=4), I don't see this being a problem in the near
future. You could have a raster of the entire earth at 4cm resolution
before this becomes a problem. I think there will be other things that
break in GRASS and many other GIS packages before we hit this limit.
I have rasters of about 30,000 rows and columns or larger and I'm
hitting the 4GB barrier pretty regularly and the lseeks are breaking. A
lot of them have been fixed already and a lot of lseeks just seek to the
beginning and do not need to be fixed, but there are still a few bad
ones around.
examples of some suspicious looking lseeks are below. I have yet to use
any of these programs, so I don't know if the fix is needed or not
r.drain/main.c: lseek(fd,list->row*ncol*sizeof(CELL),SEEK_SET);
r.drain/resolve.c: lseek(fd,(nl-1)*bnd->sz,SEEK_SET);
r.fill.dir/resolve.c: lseek(fd,(nl-1)*bnd->sz,SEEK_SET);
r.fill.dir/wtrshed.c: lseek(fm,bas[i].offset,SEEK_SET);
r.mfilter/getrow.c: lseek (fd, (long) row*len, 0);
-Andy
On Wed, 2005-09-07 at 19:16 -0700, Brad Douglas wrote:
On Wed, 2005-09-07 at 19:31 -0400, Andrew Danner wrote:
> r.thin is segfaulting on large files because of a bad type in a couple
> of lseeks.
>
> grass61.cvs/raster/r.thin/io.c
>
> lines 71 and 77 read
>
> lseek(file,(long) row * buf_len,0);
>
> but should be
>
> lseek(file, ((off_t)row) * buf_len,0);
>
> can some make the change in CVS?Done, but I really don't see it helping.
What happens if a map exceeds a number of rows greater than the max of
type int?Does it exit gracefully, or is it a disaster waiting to happen?
lib/rowio is not designed to handle very large rows, AFAICT.PS -
Take my words lightly. My ammonia levels are in the triple digits of
late and I am not thinking clearly.
Andrew Danner wrote:
r.thin is segfaulting on large files because of a bad type in a couple
of lseeks.grass61.cvs/raster/r.thin/io.c
lines 71 and 77 read
lseek(file,(long) row * buf_len,0);
but should be
lseek(file, ((off_t)row) * buf_len,0);
can some make the change in CVS?
Note: you don't need the extra brackets; type casts bind tighter than
binary operators.
--
Glynn Clements <glynn@gclements.plus.com>