[GRASS5] r.terraflow failure
endeitz
endeitz at yahoo.com
Tue Feb 21 12:17:14 EST 2006
Thanks very much for your help. However, after replacing the fseek with
fseeko, the result is the same. Can grass binaries be run under a
debugger(perhaps gdb)? That way I could easily break on the value of the
offset to see if that is where it is crashing.
Cheers,
Ed.
Andrew Danner wrote:
>
> My initial hunch is that this may be an fseek error. The function
> scan3line where the assertion fails is opening three file descriptors or
> "substreams" on a single file and calling fseek to move to the beginning
> of a particular row. However, fseek takes a 32-bit long offset which
> overflows at 2GB. There is an fseeko in most stdio.h implementations
> that takes a 64 bit off_t offset and works for larger files.
>
> Unfortunately I do not have time in the near future to investigate this
> further. My initial suggestion is to change fseek to fseeko in line 397
> of
>
> raster/r.terraflow/IOStream/include/ami_stream.h
>
> rebuild the terraflow module and see if that works. Certainly, calling
> fseek instead of fseeko is a problem, but I'm not sure if that is the
> only problem. Terraflow is using 64-bit types that handle offsets larger
> than 2GB in a lot of other places, but it may be a bit buggy in spots.
>
> If you try the fix, let me know what happens and perhaps I can help out
> some more if things are still not working.
>
>
> -Andy
>
> On Mon, 2006-02-20 at 08:24 -0800, endeitz wrote:
>> Just a followup to my previous message. Instead of using the snapshot
>> binary
>
> -snip-
>
>
--
View this message in context: http://www.nabble.com/Re%3A-GRASSLIST%3A7448-Re%3A-r.terraflow-failured-t130887.html#a3053896
Sent from the Grass5 - Dev forum at Nabble.com.
More information about the grass-dev
mailing list