Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#163 Segmentation fault when opening new file.

open
nobody
None
5
2014-01-12
2014-01-03
Anonymous
No

Hello,
when opening a new hex file I get segmentation fault.

CrossReferenceToGUI::Remove shouldn't be called!
CrossReferenceToGUI::Remove shouldn't be called!
CrossReferenceToGUI::Remove shouldn't be called!
CrossReferenceToGUI::Remove shouldn't be called!
CrossReferenceToGUI::Remove shouldn't be called!
CrossReferenceToGUI::Remove shouldn't be called!
CrossReferenceToGUI::Remove shouldn't be called!
CrossReferenceToGUI::Remove shouldn't be called!
Segmentation fault (core dumped)

gpsim 0.27 built with gputils 1.2 and gtkextra 3 on ubuntu 12.04.

Happy to assist resolving this.

Thanks

Nick

Discussion

  • Roy Rankin
    Roy Rankin
    2014-01-06

    Nick,

    I have tried running the current SVN version (before today there was a regression bug causing core dumps in the SVN version) and I do get a core dump if I do not specify the processor otherwise it seems to run with a hex file.

    Attaching a sample hex file along with the exact command used would be helpful.

    You submitted several bug reports which is fantastic, but it would be better if you would log into SourceForge before creating reports. This allows you to better track your reports. If you do not have one, create a SourceForge account.

    Regards,
    Roy Rankin

     
    • Nick Mitchell
      Nick Mitchell
      2014-01-08

      Hi Roy. Thanks for the reply.

      I'm using the GUI.
      So her's what I'm doing.
      Start gpsim from a terminal.
      Set processor with 'processor pic16f690' command.
      Load the hex file from the file menu. Load the schematic(stc) file).
      Play around a bit. All ok.
      Change some code, recompile, goto load the new hex file from the file menu. And boom. I get the segmentation fault as outlined in the op.
      Hex file attached. It's very simple there's nothing 'clever' going on.
      Thanks.

      Nick

       
  • Roy Rankin
    Roy Rankin
    2014-01-12

    Nick,

    I have been able to reproduce your issue. Gpsim is not designed to do a second load of a program. Is there any special reason you cannot stop and restart gpsim?

    Roy Rankin

     
    • Martin Habets
      Martin Habets
      2014-12-08

      To resolve this bug, and avoid similar ones in the future, I wonder if we should make the second load impossible. To me the other alternative is to make subsequent loads work, and that would be very difficult I think.

      Martin

       
  • Nick Mitchell
    Nick Mitchell
    2014-01-12

    Hello Roy,
    what I'm doing is,
    stopping gpsim, restart gpsim, enter processor name, reload hex file then reload stc file just to accomodate a change in a hex file.
    Basically it's a pain.
    If it could all be entered on the command line as start up variables then it's be neater
    e.g. gpsim processor pic16f690 hex xxxxx.hex stc xxxxx.stc
    Is this possible? Or have I missed something?
    Thanks

    Nick

     
  • Nick Mitchell
    Nick Mitchell
    2014-01-12

    Hello Roy,
    I've found the command line arguments thanks.
    Unfortunately there are bugs.

    Ta

    Nick

     
  • Roy Rankin
    Roy Rankin
    2014-01-12

    Nick,

    Normally if you are using an stc file you would have the line
    load p16f690 xxxxx.hex (or pic16f690)
    as one of the first lines of the stc file. You can then start gpsim with
    gpsim xxxxx.stc

    If the tool chain (gputils?) you are using generates a .cod file, that is what you should run in gpsim rather than the .hex file.

    Roy

     


Anonymous


Cancel   Add attachments