[GRASS5] Re: [GRASSLIST:2304] Re: s.sample gets killed

[Glynn Clements]

Hamish wrote:

> > > I added the lines to sites.c and recompiled the whole thing, but
> > > unfortunately the result is the same. Instead of 'killed' I now get
> > > a'Bus Error' message. More ideas?
> > 
> > Unfortunately not.
> > 
> > Memory exceptions (i.e. "Segmentation Fault" or "Bus Error") are
> > almost impossible to track down without a suitable test case (and
> > sending me a 2.5-million entry sites file or an equally large raster
> > are out of the question).
> > 
> > Can you reproduce the error with one of the sample data sets (e.g. 
> > spearfish), either alone or with a small additional sites file? Or
> > with data which can be generated? If so, post the details and I'll try
> > to reproduce it.
> 
> use s.random, but you have to modify it to allow n to be bigger than
> 32k. I made "int n" into "long int n" and commented out parm.nsites->options

There is no point in using a long. Any platform capable of running
GRASS will have a 32-bit int, which allows for 2,147,483,647 sites. 

Also, the value of the n= option is parsed using atoi(), which returns
an int; subsequently casting it to a long won't recover lost bits. If
you really need more than 32 bits, you need to use strtol() (and a
64-bit system; either that, or a platform which has "long long" and
strtoq()).

> (Maybe worth doing properly in CVS.. 32k is pretty small)

Yep.

> Spearfish:
> 
> g.region rast=elevation.dted
> s.random sites=random_sites n=2500000  #  (122mb)
> s.sample input=random_sites rast=elevation.dted > sample_sites
> 
> and watch it go..
> 
> 
> I think 3-4gig of virtual/swap memory will make it through the 2.5M points.

I was asking for a test case that generates the "Bus Error" message,
so that I can track it down.

-- 
Glynn Clements <glynn.clements at virgin.net>