Hello,
The initialization and compression were meant to indicate two different code blocks (sorry!). So it's not a misnamed variable problem.
---
Eventually, my colleague who was working on this problem learned about some limitations with VM management inherent in running 32-bit code (32-bit pointers) ...
namely, he observes the VM is actually flushed at 4GB, although the program would crash after 3.4GB use (because of the overhead of the OS is ~0.6GB, in practice, a total 4GB allocation isn't ever achieved for 32-bit);
you might think that the system would detect this problem and flush VM sooner; no such luck.
As a result, when re-compiling for 64-bit, the program works (i.e., VM gets flushed before running out of memory, etc.)
---
If this is indeed generally the case, we think this may be a problem for developers who use the 32-bit default and get surprised later by the "behavior" of VM management.
Travis
The block is not freed from virtual memory;
initialization: int* decomp_data = (int*) malloc(lengthOfBlock); myTableStart[block_number] = decomp_data;
compression:
int* decompress = myTableStart[block_number]; //get the pointer to the block
... do compression ...
free(decompress); //free the block <-- Frees from real memory, not from virtual memory!!!
On Apr 11, 2007, at 1:21 PM, Tony Scaminaci wrote: Correct me if I'm wrong but the pointer you created with malloc is "decomp_data" so that's the pointer that should be in the free command, i.e.:
free(decomp_data);
|