Review Board 2.0.15


switching memleak

Review Request #1283 - Created July 2, 2012 and updated

Information
Andrew Lukefahr
gem5
default
Reviewers
Default 
Changeset 9086:a6172c62f094
---------------------------
fix some memory leaks in core switching


   

  


 


 

  

  









  
 


  

 


















 

  


 


  



   

   
Ali Saidi

   
Posted  (July 2, 2012, 2:53 a.m.)


  


  


  

   
Looks good. Could you give it a quick run through valgrind to make sure there isn't any use after free issues between C++ and python?




  

   

   
    
    
   


  





  

 


  

 

















 



 

  


 


  



   

   
Ali Saidi

   
Posted  (Jan. 7, 2013, 10:25 p.m.)


  


  


  

   
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




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    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.
    
    
    
   
    2. 


   
  2. 
    
    
     
    
      
     
    
     
    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;
    
    
    
   
    3.