grads-2.0.a1 segmentation fault

[Jennifer Adams]

On Mar 20, 2008, at 3:06 PM, Steven Weiss wrote:

> Hi Jennifer,
>
> 1. Actually I generate a number of different files and it crashes
> on different ones at different places, so the time step debug wont
> help.
My suggestion would be to break it up into smaller pieces --
straighten out your code path -- that's the only way to isolate where
the problems are. There aren't many shortcuts for debugging.

> 2. Not sure what you mean by data type? Its a text or string thats
> its falling over on when trying to write to file.
I guess 'data format' would be a better word -- netcdf, grib, grib2,
binary ... There are some known problems with netcdf in 2.0.a1.

> 3. I'm not familiar with 'limit coredumpsize unlimited'  where/how
> do I set this?
I put the command just like that in my .tcshrc file, but you can
enter it at the unix command line too in order to get core files.

> 4. OK, will play with gdb to see what I can get out of it.

Good luck!

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/a396d48b/attachment.html