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