[GRASS5] RE: [GRASSLIST:2288] Re: s.sample gets killed

Laura Toma ltoma at bowdoin.edu
Wed Jan 21 12:51:01 EST 2004


If it crashes because it cannot allocate more memory, then running 
'unlimit' in the shell before running grass may help.
-Laura


On Wednesday, January 21, 2004, at 07:28 AM, Deuchler, Christoph wrote:

> Hamish, Glynn,
> as you predicted, the memory use grows until the swap space is full 
> and then the program crashes.
> 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?
>
> Thank you for your help
> Christoph
>
>
>
> -----Original Message-----
> From:	Glynn Clements [mailto:glynn.clements at virgin.net]
> Sent:	Tue 1/20/2004 7:46 AM
> To:	Hamish
> Cc:	Deuchler, Christoph; GRASSLIST at baylor.edu; grass5 at grass.itc.it
> Subject:	Re: [GRASSLIST:2288] Re: s.sample gets killed
>
> Hamish wrote:
>
>>> I need to extract raster cell values for a large number (approx. 2.5
>>> million) of sites. Unfortunately s.sample gets killed after probing a
>>> few thousand sites without apparent reason. No error message is 
>>> given,
>>> just 'killed'. Has anybody encountered the same problem and found a
>>> solution or workaround?
>>
>> Sounds like you are running out of memory.
>>
>> can you run "top" to watch the memory use while s.sample runs?
>> hit "M" while top is running to sort processes by memory use.
>>
>> Maybe it is a memory leak -- does the memory use steadily grow as the
>> program runs or is it all allocated at once? How big does it get? 
>> Please
>> post results so we can fix it if need be.
>
> It's almost certainly due to a memory leak in libgis.
>
> s.sample calls G_readsites_xyz() in a loop; G_readsites_xyz() calls
> G_site_new_struct() to allocate a Site structure and
> G_site_free_struct() to free it.
>
> G_site_new_struct() allocates the dim, str_att and dbl_att arrays, and
> also allocates a buffer for each entry in the str_att array.
> G_site_free_struct() frees these arrays, but *doesn't* free the
> buffers in the str_att array.
>
> The attached patch fixes that; however, it should probably be tested
> before being commited. AFAICT, the following programs may be affected:
>
> d.extend d.pan d.site.labels d.site.pg d.sites d.sites.qual
> d.vect.labels d.what.sites d.zoom g.region m.in.e00 p.map p.map.new
> ps.map r.cost r.random r.to.sites r.volume s.delaunay s.hull
> s.in.ascii s.in.dbf s.info s.in.shape s.mask s.out.ascii s.out.e00
> s.perturb s.proj s.qcount s.random s.sample s.surf.idw s.surf.rst
> s.territory s.to.rast s.to.vect s.vol.rst s.voronoi s.what s.windavg
> v.circle v.in.tig.lndmk v.surf.rst v.to.sites v.out.moss NVIZ
>
> -- 
> Glynn Clements <glynn.clements at virgin.net>
>
>
>
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>




More information about the grass-dev mailing list