I believe that this change is in the process of being merged. Doug
$ svn log -r 3212 https://svn.open64.net/svnroot/open64/branches/x86_open64-4.2.4 ------------------------------------------------------------------------ r3212 | dcoakley | 2010-06-08 16:30:52 -0700 (Tue, 08 Jun 2010) | 6 lines Fix a free-of-unallocated-memory bug. As stated in one of the comments, only the first node in the sequence of blocks created by Update_Map is potentially an allocated pointer. ------------------------------------------------------------------------ $ svn diff -c 3212 https://svn.open64.net/svnroot/open64/branches/x86_open64-4.2.4 Index: osprey/common/com/cmplr_segmented_array.h =================================================================== --- osprey/common/com/cmplr_segmented_array.h (revision 3211) +++ osprey/common/com/cmplr_segmented_array.h (revision 3212) @@ -469,7 +469,7 @@ map.push_back(pair<T*, BOOL>(marker, own_memory)); new_size -= block_size; marker += block_size; - own_memory += false; //Only the first entry can be freed for a block that + own_memory = FALSE; //Only the first entry can be freed for a block that //is larger than block_size. By: Jon Hsu, 11 May 2001. } while (new_size); } // RELATED_SEGMENTED_ARRAY<T,block_size>::Update_Map Index: osprey/common/com/segmented_array.h =================================================================== --- osprey/common/com/segmented_array.h (revision 3211) +++ osprey/common/com/segmented_array.h (revision 3212) @@ -359,9 +359,9 @@ { do { map.push_back(std::pair<T*, BOOL>(marker, own_memory)); - // own_memory = FALSE; new_size -= block_size; marker += block_size; + own_memory = FALSE; } while (new_size); } // SEGMENTED_ARRAY<T,block_size>::Update_Map Property changes on: . ___________________________________________________________________ Modified: svk:merge - 6db51eb9-ef60-0410-a809-350791640a1b:/stage:1009 + 6db51eb9-ef60-0410-a809-350791640a1b:/stage:1010 $ From: Mike Murphy [mailto:mmur...@nvidia.com] Sent: Wednesday, July 07, 2010 3:56 PM To: open64-devel@lists.sourceforge.net Subject: [Open64-devel] memory bug in cmplr_segmented_array.h We ran into a subtle bug in cmplr_segmented_array.h and wanted to run our proposed fix by the group, particularly since this bug seems to have existed in the code for a long time. The problem occurs in Update_Map, where the code was: own_memory += false; //Only the first entry can be freed for a block that //is larger than block_size. By: Jon Hsu, 11 May 2001. Note that += false is a no-op, so this doesn't really do what the comment says. In the corresponding segmented_array.h the line is commented out: // own_memory = FALSE; which also seems wrong. Our fix is to set own_memory = false in both of these cases. Without this fix what happens is that RELATED_SEGMENTED_ARRAY::Allocate does a single MEM_POOL_Alloc and then calls Update_Map with the allocated block. If new_size>block_size then Update_Map pushes entries for multiple chunks in the block (in the case that triggered this I had a 512 new_size with 128 block_size, so it created 4 entries in the map, at base,base+128.base+256,base+384). Then in ~RELATED_SEGMENTED_ARRAY() it iterates through these map entries doing: // entry->second <==> this map entry owns the block's memory. if (entry->second) { MEM_POOL_FREE(pool, entry->first); } Since own_memory was never reset to false, entry->second is always true and we will then call MEM_POOL_FREE on not only the initial base address that was MEM_POOL_Alloc, but also on the subsequent offsets (base+128,base+256,base+384). When pool == Malloc_Mem_Pool, then MEM_POOL_FREE does an explicit free of this address, which will corrupt the heap when doing free of an address that was not originally malloc'ed (like base+128). ________________________________________ This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
