grads-2.0.a1 segmentation fault
Steven Weiss
sweiss at IAFRICA.COM
Thu Mar 20 16:17:58 EDT 2008
I have approx 120 mb free memory. The machine has 2GB
If I run script with -blc it uses approx 65 mb and exits normally.
If I run script through command line it uses around 7 mb and fails
The interesting bit now is that I'm always getting a seg fault via the command line and have not had 1 yet using the -blc
----- Original Message -----
From: Jennifer Adams
To: GRADSUSR at LIST.CINECA.IT
Sent: Thursday, March 20, 2008 10:07 PM
Subject: Re: grads-2.0.a1 segmentation fault
On Mar 20, 2008, at 3:25 PM, Steven Weiss wrote:
Hi Jennifer,
I think I may have discovered the area where the problem lies. Its difficult to prove due to the inconsistency and nature of the problem.
1. grads -blc 'myscript.gs' - produced no seg faults in 10 runs
2. grads -b
landscape
myscript.gs
produced seg faults approx 30% of the time.
It may just be an anomaly but the software appears to be more stable with the -blc.
I think this is a red herring.
This I can live with. Time will tell I guess.
Try Arlindo's suggestion to track your memory use with 'top' . That may provide more clues.
Jennifer
Regards
Steven
----- Original Message -----
From: Jennifer Adams
To: GRADSUSR at LIST.CINECA.IT
Sent: Thursday, March 20, 2008 8:47 PM
Subject: Re: grads-2.0.a1 segmentation fault
On Mar 20, 2008, at 1:50 PM, Steven Weiss wrote:
Hi Jennifer,
Yes, I am looping around the time variable and calling a number of nested
functions that return a string variable which I print to a file.
The problem is that its inconsistent so its hard to put the debug code in.
The script is approx 1000 lines.
At the very least you could put something in to say what time step you're at.
There is no core.
Use 'limit coredumpsize unlimited' to get core files. On a mac, they get put in /cores
I will have to try see if I can catch it.
Can't really help without more specific info. What data type are you using??
Is there no possibility that you can run in debug mode e.g. grads --debug?
What would you have 'grads --debug' do for you?
You can try running grads inside the GNU debugger...
> gdb grads
...
(gdb) set args -lbc 'myscript.gs'
(gdb) run
... then, when it seg faults, use the 'where' command to find out what caused the crash.
Jennifer
Regards
Steven
----- Original Message -----
From: "Jennifer Adams" <jma at COLA.IGES.ORG>
To: <GRADSUSR at LIST.CINECA.IT>
Sent: Thursday, March 20, 2008 6:28 PM
Subject: Re: grads-2.0.a1 segmentation fault
On Mar 20, 2008, at 8:10 AM, Steven Weiss wrote:
Hi,
I'm running grads 2.0.a1 on Suse Linux and every so often I get a
segmentation fault. Its very inconsistent. The only thing I can see
is that
it is always during writing out a file. i.e. rc= write (filename,
variable).
From looking at the file, the variable data is normally only half
written
and the problem is not always in the same place.
How can I go about identifying what the problem is?
Well ...
I can't fix I bug I can't reproduce, so you have to find a way to get
GrADS to seg fault reliably. Try putting some debugging statements in
your script so you'll know where it's dying, e.g. if it happens
during a loop. There are some known problems in 2.0.a1 that have
already been addressed ... what data type are you using?
If you've got a core file, you can try using gdb (gnu debugger) to
see where it died:
> gdb grads
...
(gdb) core your.core.filename
Then gdb will say where in the GrADS code it was when it seg faulted.
Jennifer
--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jma at cola.iges.org
--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jma at cola.iges.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20080320/474143e7/attachment.html
More information about the gradsusr
mailing list