2019-06-26 08:40 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000243mercuryBugpublic2011-12-07 22:29
Reporterjuliensf 
Assigned Tojuliensf 
PriorityurgentSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0000243: Memory zone leak on Windows
DescriptionThis documents a series of problems that Ian has encountered with memory zones on Windows.

Executables built in the hlc.gc.trseg grade are leaking memory zones on Windows. The immediate
cause of the problem is that the call to VirtualFree at runtime/mercury_memory_zones.c:212 is failing
(it doesn't show because the return value is not checked). Looking closer, I think there are a whole
series of problems with the VirtualAlloc approach to allocation for memory zones:

(1) it isn't clear that we are allocating memory correctly in the first place, i.e. doesn't the call
     to VirtualAlloc at runtime/mercury_memory_zones.c:177 also have to reserve the memory
     as well as commit it.

(2) the call to VirtualFree mentioned above doesn't match the API documentation that says that if
     we call VirtualFree with MEM_RELEASE then the size argument must be 0. (Changing this value
     to 0 just resulted in a segmentation fault.) We should also check the return value of any calls
    to VirtualFree.

(3) MR_protect_pages should probably be calling VirtualProtect, *not* VirtualAlloc.

(4) When we allocate a zone using VirtualAlloc when using the Boehm GC we call GC_add_roots
on the range of memory returned. We do not call GC_remove_roots when deallocating the zone.
(Which wouldn't work on Windows since Boehm doesn't appear to implement GC_remove_roots on
Windows.)

In light of the above, I think the approach using VirtualAlloc doesn't work and we should use the
version of the zone functions that use the Boehm collector on Windows.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000433

juliensf (administrator)

Fix committed.
+Notes

-Issue History
Date Modified Username Field Change
2011-12-05 16:44 juliensf New Issue
2011-12-05 16:44 juliensf Status new => assigned
2011-12-05 16:44 juliensf Assigned To => juliensf
2011-12-07 22:29 juliensf Note Added: 0000433
2011-12-07 22:29 juliensf Status assigned => resolved
2011-12-07 22:29 juliensf Resolution open => fixed
+Issue History