traj.gs

[Takashi Kagimoto]

Dear Ted,

From: Ted Pollock <edwardp at UALBERTA.CA>
Subject: traj.gs
Date: Wed, 8 Aug 2007 23:36:33 +0200

> I am running the script traj.gs on some high temporal resolution MM5 data.
> The script has to be run 49 times per output image file. The trouble is that
> after around 5 to 6 trajectory calculations grads crashes with the following
> error: Segmentation fault (core dumped). Each trajectory calculation runs
> slower then the last so it is some kind of memory problem but the coredump
> file size is only 5.2 Mb.
>
> I have tried setting the memory limits and core dump size very high with
> little success.

I think this is a potential bug in GrADS. Looking at src/gauser.c,
you will see a counter that express how many times d(isplay)
command is spawn, pcm->pass. This counter will increase forever
unless you run c(lear) command or you draw a sort of animation.
In fact, there are thousands of d(isplay) commands in traj.gs.
So what is the problem in this counter? The counter is used to
determine a color of an object, if you do not specify it, in the
way of dcolor[pcm->pass+1], which is defined in the function of
gadspl() as to be in the following,

  static int dcolor[10] = {-1, 1, 3, 7, 2, 6, 9, 10, 11, 12 };

What will happen when the counter value becomes larger than or
equal to 10. If the memory address corresponding to dcolor[n],
although it's grammatically an illegal access, is a sort of data
area that is assigned to your program (in this case, GrADS), you
may luckily draw an object with some color, where n is any negative
value or any value larger than or equal to 10. If not, you will
encounter the segmentation fault.

I attached a patch file to modify this problem for GrADS 1.9b4.
Namely you need to build executables of grads from source codes.
Hope you will successfully do it.

Best regard
----
Takashi Kagimoto
Frontier Research Center for Global Change/JAMSTEC
3173-25 Showamachi, Kanazawa-ku, Yokohama, Kanagawa 236-0001, JAPAN
(tel) +81-45-778-5516 (fax) +81-45-778-5707