[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