[GRASS-dev] r.flow: crash on 64bit

On Mon, 2007-01-29 at 22:39 +0100, Markus Neteler wrote:

Hi,

when using r.flow on 64bit, it crashes (Spearfish example):
r.flow elevation.dem flout=flout lgout=lgout dsout=dsout
Reading input files: elevation
Precomputing: tangents
Precomputing: e/w distances
Precomputing: quantization tolerances
Precomputing: interpolated border elevations
Precomputing: aspects
Calculating maps ...
Segmentation fault

It dies in calc.c:223.

'aspin' and 'barin' inputs are apparently not optional. It segv()s
because the variables point to invalid memory segments.

I take it the module should function with the parameters you used? Let
me know so I can either track it down or issue the proper error and exit
gracefully.

From first glace, the module could really use a good rewrite. It

doesn't seem to have been touched (other than minor maintenance) in some
time. I'm sure the mathematical integrity is in tact, but it is a bit
confusing to navigate due to long macros that should probably be
functions and functions that should be combined. Code normally found in
main() is split up into several functions "daisy chained" together.
I'll put it at the bottom of my queue for now...

--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785

Brad Douglas wrote on 01/30/2007 12:45 PM:

On Mon, 2007-01-29 at 22:39 +0100, Markus Neteler wrote:
  

Hi,

when using r.flow on 64bit, it crashes (Spearfish example):
r.flow elevation.dem flout=flout lgout=lgout dsout=dsout
Reading input files: elevation
Precomputing: tangents
Precomputing: e/w distances
Precomputing: quantization tolerances
Precomputing: interpolated border elevations
Precomputing: aspects
Calculating maps ...
Segmentation fault

It dies in calc.c:223.
    
'aspin' and 'barin' inputs are apparently not optional. It segv()s
because the variables point to invalid memory segments.
  

Brad,

both parameters should be optional. And on 32bit there is no such problem, it works.

I take it the module should function with the parameters you used? Let
me know so I can either track it down or issue the proper error and exit
gracefully.
  

I am afraid that it is really a bug somewhere.

Markus

From first glace, the module could really use a good rewrite. It
doesn't seem to have been touched (other than minor maintenance) in some
time. I'm sure the mathematical integrity is in tact, but it is a bit
confusing to navigate due to long macros that should probably be
functions and functions that should be combined. Code normally found in
main() is split up into several functions "daisy chained" together.
I'll put it at the bottom of my queue for now...