- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am working in x64 mode with IVF 9.1. My app needs lots of RAM, so I have 96 GB of virtual memory available, and I use it. (That's 32 GB actual RAM plus 64 GB pagefile.) I am running under Windows (HPC 2008).
I have encountered a case where a memory access error occurred on a deallocate of a large array. Going deep into the debugger, I can see that the memory for the array was allocated via kernel32!VirtualAlloc, but when it comes time to free it, it goes to some FreeHeap routine instead of kernel32!VirtualFree. Pressing on I see that the runtime keeps a table of addresses of the blocks of virtual memory it has allocated, and references this table to decide whether to call VirtualFree or something else. Specifically, if the address I want to free is in the table, then it must have been allocated with VirtualAlloc, so VirtualFree will be called.
The problem is that the table consists of 256 entries and is indexed by bits 25 through 32 of the address returned by VirtualAlloc. So if another allocated block matches in those bits, it will overwrite a previous entry in the table. When it comes time for the first block to be freed, its address is not in the table, so "free" is called instead of VirtualFree, which leads to a memory fault.
The 256 entry table suffices if all allocated blocks fall under a 4 GB limit. Addresses under 4 GB don't have any bits on above bit 32. But with 96 GB of virtual memory that my app needs to use, I exceed this limit often. Every time I deallocate an array I am taking a chance that my app will fail.
So through oversight, I believe, the 9.1 runtime that I have does not support more than 4 GB of virtual memory, even though it is in x64 mode.
What can I do? Are any patches issued for those runtimes? Or am I forced to move my project to IVF 11.0?
Thanks,
Chuck
I have encountered a case where a memory access error occurred on a deallocate of a large array. Going deep into the debugger, I can see that the memory for the array was allocated via kernel32!VirtualAlloc, but when it comes time to free it, it goes to some FreeHeap routine instead of kernel32!VirtualFree. Pressing on I see that the runtime keeps a table of addresses of the blocks of virtual memory it has allocated, and references this table to decide whether to call VirtualFree or something else. Specifically, if the address I want to free is in the table, then it must have been allocated with VirtualAlloc, so VirtualFree will be called.
The problem is that the table consists of 256 entries and is indexed by bits 25 through 32 of the address returned by VirtualAlloc. So if another allocated block matches in those bits, it will overwrite a previous entry in the table. When it comes time for the first block to be freed, its address is not in the table, so "free" is called instead of VirtualFree, which leads to a memory fault.
The 256 entry table suffices if all allocated blocks fall under a 4 GB limit. Addresses under 4 GB don't have any bits on above bit 32. But with 96 GB of virtual memory that my app needs to use, I exceed this limit often. Every time I deallocate an array I am taking a chance that my app will fail.
So through oversight, I believe, the 9.1 runtime that I have does not support more than 4 GB of virtual memory, even though it is in x64 mode.
What can I do? Are any patches issued for those runtimes? Or am I forced to move my project to IVF 11.0?
Thanks,
Chuck
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We don't do "patches" - if there was a 9.1 update to fix this issue (which is unfamiliar to me), then it would be in the last 9.1 update available. 9.1 is no longer a supported version.
You can try a 30-day trial of 11.0 and see if the problem is still there.
You can try a 30-day trial of 11.0 and see if the problem is still there.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page