Re: [Gems-users] Ruby initialization fails in simics 3.0.18

[Dan Gibson <degibson@xxxxxxxx>]

Ahh... my apologies for the panic! I'm glad it turned out to be 
something so simple.
Mishali Naik wrote:
> Thanks a lot Dan and Mike,
>             I just realized that my checkpoint was only for 1 cpu.
> Before, I was using gems with simics 2.2 using bagle machine. And when
> I switched to 3.0 I started using abisko and I forgot to set the
> machine parameter num_cpus which is by defualt 1.
>
> -Mishali
>
> On 9/11/06, Dan Gibson <degibson@xxxxxxxx> wrote:
>   
> > I spent a lot of time figuring out this issue with Simics 3.0.5. I
> > finally tracked down the segmentation fault to something going on within
> > the standard C++ string library, which suggested memory corruption.
> >
> > The root of the issue is that Simics is linked against an older version
> > of glibc, which handles memory management a little differently than more
> > modern versions. We made a simple module to verify the issue.
> >
> > To figure out if the version incompatibility is indeed the issue, please
> > do the following:
> >
> > Open $GEMS/ruby/init.C and place the following lines at the start of the
> > init_simulator() function:
> >
> > cout << "Hello World" << endl << flush;
> > string desc = string("Hello World, ")+string("01")+string("
> > ")+string("02")+string(" ")+string("03");
> > cout << desc << endl << flush;
> >
> > If you see Hello World followed by a segmentation fault, we're dealing
> > with the same problem.
> > If you see the whole string, we might be dealing with a separate
> > problem. I say *might* because it is likely that changes from 3.0.5 ->
> > 3.0.18 have fixed the above problem and introduced new ones -- they
> > dynamic interaction of memory allocations/deallocations are enormously
> > difficult to debug.
> >
> > IF a glibc compatibility issue is at the root of the problem, there are
> > essentially three options:
> > 1) Use an old version of gcc/glibc to compile ruby -- the same version
> > used by Simics would be ideal.
> > 2) Ask Virtutech to do one of the following:
> > A) Provide a copy of the Simics 3.0.11 tarball (known to work with Ruby)
> > (fat chance)
> > B) Provide a compiled version of Simics that used a modern gcc/glibc.
> > (fat chance)
> > 3) Use Simics 2.2.19 instead of 3.0.X.
> >
> > Regards,
> > Dan
> >
> > Mishali Naik wrote:
> >     
> > > I am using gcc 3.4.4. thanks for the prompt reply. I have spent quite
> > > sometime trying to figure out...
> > >
> > > On 9/11/06, Dan Gibson <degibson@xxxxxxxx> wrote:
> > >
> > >       
> > > > This sounds like an issue I ran into some time ago relating to glibc.
> > > > Essentially, there was a version incompatibility between my compiler the
> > > > compiler used to compile Simics.
> > > >
> > > > What version of gcc are you using?
> > > >
> > > > Regards,
> > > > Dan Gibson
> > > >
> > > > Mishali Naik wrote:
> > > >
> > > >         
> > > > > Hi,
> > > > >         I am trying to initialize the ruby module with ruby0.init in
> > > > > simics 3.0.18. But the initialization fails because of a segementation
> > > > > fault:
> > > > >
> > > > > Turning I-STC off and flushing old data
> > > > > Turning D-STC off and flushing old data
> > > > > successful installation of the ruby timing model.
> > > > > Ruby Timing Mode
> > > > > Creating event queue...
> > > > > Creating system ...
> > > > >     Processors : 8
> > > > > Segmentation fault (SIGSEGV) in main thread.
> > > > > The simulation state has been corrupted. Simulation cannot continue.
> > > > >
> > > > >            I traced the calls and the assertion in
> > > > > pc_step_t SIM_step_count(conf_object_t *p) { assert(0); return 0; };
> > > > > //fails for the processor 1. This function is being called by
> > > > > integer_t SIMICS_get_insn_count(int cpuNumber)
> > > > > {
> > > > >   processor_t* cpu = SIM_proc_no_2_ptr(cpuNumber);
> > > > >    return SIM_step_count((conf_object_t*) cpu);
> > > > >
> > > > > }
> > > > >
> > > > > Processor 0 gets initialized fine.
> > > > >
> > > > >                             I appreciate all your help.
> > > > >
> > > > > thanks,
> > > > > Mishali
> > > > > _______________________________________________
> > > > > Gems-users mailing list
> > > > > Gems-users@xxxxxxxxxxx
> > > > > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > > > > Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
> > > > >
> > > > >
> > > > >
> > > > >           
> > > > --
> > > > http://www.cs.wisc.edu/~gibson [esc]:wq!
> > > >
> > > > _______________________________________________
> > > > Gems-users mailing list
> > > > Gems-users@xxxxxxxxxxx
> > > > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > > > Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
> > > >
> > > >
> > > >
> > > >         
> > > _______________________________________________
> > > Gems-users mailing list
> > > Gems-users@xxxxxxxxxxx
> > > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > > Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
> > >
> > >
> > >       
> > --
> > http://www.cs.wisc.edu/~gibson [esc]:wq!
> >
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
> >
> >
> >     
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>
>   
--
http://www.cs.wisc.edu/~gibson [esc]:wq!