#163 Segmentation fault when opening new file.

[Anonymous]

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

[Roy Rankin]

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]

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]

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 H]

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]

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]

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

Ta

Nick

[Roy Rankin]

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

[fenugrec]

Hi,
seems this is still relevant now with gpsim 0.29.0 --

Gpsim is not designed to do a second load of a program.

That's very unfortunate (makes it harder to do a "simulate -> recompile -> reload -> simulate ..." iterative process, as has been pointed out. But, fair enough - would it be possible to at least not segfault !
partial backtrace (sorry, I don't have gpsim compiled with -g) :

#0  0x00007ffff7375b98 in GUI_Interface::UpdateObject(void*, int) () at /usr/lib/libgpsimgui.so.0
#1  0x00007ffff7a4529f in gpsimInterface::update_object(void*, int) () at /usr/lib/libgpsim.so.0
#2  0x00007ffff7adfb5b in XrefObject::_update() () at /usr/lib/libgpsim.so.0
#3  0x00007ffff7a45347 in gpsimInterface::simulation_has_stopped() () at /usr/lib/libgpsim.so.0
#4  0x00007ffff7a36f56 in PicCodProgramFileType::LoadProgramFile(Processor**, char const*, _IO_FILE*, char const*) () at /usr/lib/libgpsim.so.0
#5  0x00007ffff7ac3453 in ProgramFileTypeList::LoadProgramFile(Processor**, char const*, _IO_FILE*, char const*) () at /usr/lib/libgpsim.so.0
#6  0x00007ffff7ac6d18 in CSimulationContext::LoadProgram(char const*, char const*, Processor**, char const*) () at /usr/lib/libgpsim.so.0

[Luis Claudio Gambôa Lopes]

I have a similar problem (maybe it's the same cause) using the gpsim 0.31.0 library. Apparently when an .hex file is loaded some interface objects are created (in the PIC that I tested the timer creates an interface). When a file is loaded again, new interface objects are created and the old ones become invalid, when some function accesses these invalid interfaces it causes a segmentation fault.
The get_interface (). clear () method exists but does nothing because it has no code, and is not called anywhere in gpsim.

The ugly temporary solution I found was to force the interfaces to be removed between hex loading.

 CSimulationContext::GetContext ()->Clear ();
 //get_interface().clear(); //does nothing 
 for(int i=0;i< 1000;i++) //remove all interfaces 
  {
    get_interface().remove_interface (i);
  }

as each time a file is loaded the number of interfaces is increased and I cannot access the number of interfaces created, I delete all interfaces from 0 to 1000. Trying to remove an interface that does not exist does not cause any problem. Of course, this works as long as less than 1000 interfaces are generated.

Everything would be solved to me if the get_interface().clear() method was implemented to delete the interfaces and reset the interface counter, but I don't know how it would impact the rest of the simulator, since I only use the library.