grads-2.0.a1 segmentation fault

[Jennifer Adams]

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20080320/a6d6d40e/attachment.html