[GRASS5] D.vect.graph problem

[Michael Barton]

Hamish,

I did what you suggested. When I run d.vect.chart using bar graphs, the
process (along with a dbf process) very briefly flashes in top then
disappears as it finishes.

However, if I do it with a pie chart it is a very different story. CPU use
zooms up to over 80% for awhile and memory use starts to climb rapidly.
RPRVT and RSIZE climbed to over 200 Mb (I have 512 Mb installed in my Mac
laptop and had several other apps running, but paused and using limited
RAM). VSIZE climbed to over 530 Mb. As memory use climbed, CPU use dropped
way down (0.8%) and stayed low from then on. Memory use stabilized at around
230Mb for RPRVT and RSIZE and 534Mb for VSIZE.

I had to kill it. Kill worked OK (i.e., no need for xkill), though
everything was slow as molasses. I went ahead and quit X11 then. Things seem
to have gotten back to normal now, without rebooting.

So what is going on? Is this happening to anyone else? Is it just Mac's? Is
it just my system?

Cheers
Michael


On 8/31/04 12:53 AM, "Hamish" <hamish_nospam at yahoo.com> wrote:

>> I want to re-report a problem with d.vect.graph.
>> 
>> I have a point file in GRASS 5.7 (binaries from 22-07-2004 on Mac OSX
>> 10.3.5). It displays fine in a UTM location.
>> 
>> If run d.vect.graph and I select a bar graph, all works fine.
>> 
>> If I select a pie chart, my computer slows to a crawl--all processes,
>> not just GRASS. Once I managed to get some of the pie graphs,
>> including a partly drawn graph before the computer dropped to low
>> gear. I checked processes on this once and GRASS was eating up nearly
>> all the processing power and available memory. I literally have to do
>> a hard restart on the computer to get control of it again.
>> 
>> I did NOT set a pie chart size column (it says optional). I left the
>> rest at the default or the settings that worked fine for bar graphs.
> 
> 
> Works for me in Linux.
> 
> Sounds like a memory leak, how many points are you displaying?
> 
> When you say "GRASS was eating up nearly all the processing power and
> available memory" do you mean the d.vect.chart program specifically?
> 
> hint:
> Try running 'top' in another terminal window. You can watch the
> process go haywire and then press "k" and enter its PID to kill it.
> 'pkill d.vect.chart' might help too. 'xkill' is the most fun of course.
> If it fails to die, you can send it stronger signals. see the kill help
> pages.
> 
> 
> 
> Hamish

____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ  85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>