I update the patch to add more comments.

In this situation, priority_fn has a member __curbb_list witch is a
std::list, it would not use the memory pool _hb_pool, but cycle_fn has
not member that use memory outside pool _hb_pool

Index: osprey/be/cg/hb_sched.cxx
===================================================================
--- osprey/be/cg/hb_sched.cxx   (revision 3678)
+++ osprey/be/cg/hb_sched.cxx   (working copy)
@@ -2951,6 +2951,9 @@
 #if defined (TARG_SL)
   LOCS_Fwd_Scheduling = org_LOCS_Fwd_Scheduling;
 #endif
+  // cycle_fn  will be deleted when _hb_pool is freed, while
priority_fn used malloc pool
+  // to initialize its _curbb_list, so we explicitly delete it to
aviod memory leak.
+  CXX_DELETE(priority_fn, &_hb_pool);
 }

 void

On Thu, Jul 7, 2011 at 10:12 AM, Jian-Xin Lai <laij...@gmail.com> wrote:
> Another object cycle_fn is allocated in the same way as priority_fn
> and it's not freed, too. Could you please also check the cycle_fn?
>
> 2011/7/4 Wu Yongchong <wuyongch...@gmail.com>:
>> Can a gate keeper help review this patch
>>
>> Class Priority_Selector(declared in open64/osprey/be/cg/hb_sched.h)
>> has a member std::list<BB*> _curbb_list . Although we use local memory
>> pool when we call the constructor, the _curbb_list still use new
>> operator to allocate memory. So that this memory block is leaked even
>> if the local memory pool is freed. This patch will call the destructor
>> explicitly.
>>
>> Index: osprey/be/cg/hb_sched.cxx
>> ===================================================================
>> --- osprey/be/cg/hb_sched.cxx   (revision 3669)
>> +++ osprey/be/cg/hb_sched.cxx   (working copy)
>> @@ -2951,6 +2951,7 @@
>>  #if defined (TARG_SL)
>>   LOCS_Fwd_Scheduling = org_LOCS_Fwd_Scheduling;
>>  #endif
>> +  CXX_DELETE(priority_fn, &_hb_pool);
>>  }
>>
>>  void
>>
>> --
>> yongchong
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Open64-devel mailing list
>> Open64-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>
>
>
>
> --
> Regards,
> Lai Jian-Xin
>



-- 
yongchong

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel

Reply via email to