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