grads-2.0.a1 segmentation fault
Steven Weiss
sweiss at IAFRICA.COM
Tue Apr 1 03:02:17 EDT 2008
Hi Jennifer,
The problem is now occurring inconsistently in both batch mode and from command line.
I've tried using top to examine the memory and there is no issue here. I've also cleared cache memory i.e. "echo 1 > drop_caches"
I've also tried rebooting and this has made no difference either.
I've managed to get the following below through gdb and also have a core which I generated through gdb (21mb).
Any suggestions moving forward?
Regards
Steven
linux-3vnb:/home/wavescape/grads-2.0.a1/work # gdb grads
GNU gdb 6.6.50.20070726-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) set args -b
(gdb) run
Starting program: /home/wavescape/grads-2.0.a1/bin/grads -b
Grid Analysis and Display System (GrADS) Version 2.0.a1
Copyright (c) 1988-2008 by Brian Doty and the
Institute for Global Environment and Society (IGES)
GrADS comes with ABSOLUTELY NO WARRANTY
See file COPYRIGHT for more information
Config: v2.0.a1 little-endian readline printim grib2 netcdf hdf4-sds
Issue 'q config' command for more information.
Landscape mode? ('n' for portrait):
GX Package Initialization: Size = 11 8.5
Running in Batch mode
ga-> wavescape.gs
Program received signal SIGSEGV, Segmentation fault.
0x0808a4cd in gsfmath (pcmn=0x37333237, mathflg=875771443) at gscrpt.c:3313
3313 gscrpt.c: No such file or directory.
in gscrpt.c
(gdb) where
#0 0x0808a4cd in gsfmath (pcmn=0x37333237, mathflg=875771443)
at gscrpt.c:3313
#1 0x31363930 in ?? ()
#2 0x37333237 in ?? ()
#3 0x34333633 in ?? ()
#4 0x34303538 in ?? ()
#5 0x33303030 in ?? ()
#6 0x38353936 in ?? ()
#7 0x36313937 in ?? ()
#8 0x30393835 in ?? ()
#9 0x37363538 in ?? ()
#10 0x34363533 in ?? ()
#11 0x33373430 in ?? ()
#12 0x34383432 in ?? ()
#13 0x33313635 in ?? ()
#14 0x32383239 in ?? ()
#15 0x32343937 in ?? ()
#16 0x34363138 in ?? ()
#17 0x30363634 in ?? ()
#18 0x30333338 in ?? ()
#19 0x35383930 in ?? ()
#20 0x39343830 in ?? ()
#21 0x35343039 in ?? ()
#22 0x36323934 in ?? ()
---Type <return> to continue, or q <return> to quit---
#23 0x34373033 in ?? ()
#24 0x33393437 in ?? ()
#25 0x32383335 in ?? ()
#26 0x33333838 in ?? ()
#27 0x35393431 in ?? ()
#28 0x36333338 in ?? ()
#29 0x0030302e in ?? ()
#30 0x00000001 in ?? ()
#31 0x00000000 in ?? ()
(gdb)
----- 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/20080401/67dc7f19/attachment.html
More information about the gradsusr
mailing list