> On Jan. 8, 2013, 6:25 a.m., Ali Saidi wrote:
> > HI Andrew,
> > 
> > Do you still believe this change is correct? It looks fine to me, but I've 
> > run into various kinds of memory corruption with the events as they get 
> > pasesd back between python and c++, so I would like to make sure that 
> > you're still using this code before we commit it.
> > 
> > Thanks,
> > Ali
> >
> 
> Anthony Gutierrez wrote:
>     I had this patch applied in my code, it never caused any problems. 
> Granted, it was probably not tested extensively because the simulator would 
> die for other reasons. I'll check it out with new changes and see if it's ok.

I am in the process of bringing my codebase in line with the current Gem5 repo, 
so I'm afraid I can't comment at this time on how well these patches work for 
newer revisions.  

I haven't looked at the new DrainManager, but, in the codebase I was working 
with, the python simulate() would reference the C++ simulate() that returned a 
pointer to an dynamically allocated event which was then ignored by the python. 
 So the event's memory was never freed.  I added the cleanupExitEvent() code so 
that they python scripts can explicitly free that event's memory.  

The other leak occurs when gem5 drops out of simulation for something other 
than the originally scheduled limit_event.  In my case, I called exitSimLoop() 
within the C++, which generated another exit event.  The original limit_event 
was then left in the eventQueue. When gem5 re-entered simulation, it scheduled 
another limit_event, so the queue was constantly filling with limit_events. I 
think the following lines are still relevant, as they are designed to 
deschedule the limit_event from the eventQueue when gem5 drops out of 
simulation for something other than the original limit event:

- hack_once("be nice to actually delete the event here");
+ mainEventQueue.deschedule(limit_event);
+ delete limit_event;


- Andrew


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1283/#review3789
-----------------------------------------------------------


On July 2, 2012, 9:36 a.m., Andrew Lukefahr wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1283/
> -----------------------------------------------------------
> 
> (Updated July 2, 2012, 9:36 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Description
> -------
> 
> Changeset 9086:a6172c62f094
> ---------------------------
> fix some memory leaks in core switching
> 
> 
> Diffs
> -----
> 
>   src/python/m5/simulate.py 5f0321c03a2602f34dd03700e41e0cf5b47b8761 
>   src/python/swig/pyevent.hh 5f0321c03a2602f34dd03700e41e0cf5b47b8761 
>   src/python/swig/pyevent.cc 5f0321c03a2602f34dd03700e41e0cf5b47b8761 
>   src/sim/simulate.cc 5f0321c03a2602f34dd03700e41e0cf5b47b8761 
> 
> Diff: http://reviews.gem5.org/r/1283/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Andrew Lukefahr
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to