0000243: Memory zone leak on Windows

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000243

mercury

Bug

public

2011-12-05 16:44

2011-12-07 22:29

Reporter

juliensf

Assigned To

juliensf

Priority

urgent

Severity

minor

Reproducibility

always

Status

resolved

Resolution

fixed

Product Version

Target Version

Fixed in Version

Summary

0000243: Memory zone leak on Windows

Description

This 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.

Date Modified	Username	Field	Change
Issue History
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

Relationships