Garbage Collector Question
BlitzMax Forums/BlitzMax Programming/Garbage Collector Question
| ||
| When the GC collects memory and 'frees' it, is the memory zeroed or is our data still technically in the GC's memory pool? |
| ||
| I'd like an answer to this too. |
| ||
| Before the automatic GC was implemented, the memory was repooled for later usage and freed if not used for some time. As strings still raise the memory usage until a given amount of memory where it stagnates, I assume that it still repools the memory. |
| ||
| But when the memory is collected, is it zeroed or is the data still there, although set aside for later use? If it isn't zeroed, that's kindof an obscene security hole.. |
| ||
| Personally, I'd prefer it if the data were not zeroed when it gets collected, purely from a performance perspective. If you are doing something that genuinely needs to worry about security, I would suggest that you should be explicitly trashing the data before getting rid of it. I know I would, even if I was told that the collector was supposed to do it for me... |
| ||
| What compiler zero's the memory before it free it? |
| ||
| Noel, how is this a security hole? Remember, other processes can't access the memory of your application, so they can't seee the data. And different apps don't share memory pages either. Not zeroing memory upon freeing is exactly how the C runtime library works. (If you're thinking that another app could all of a sudden get a page of old data from another app, then that won't happen. Like I said above, apps don't share memory pages, and when a new page is allocated to an application, it's cleared by the OS-level memory manager.) |
| ||
| No, I'm thinking that another application (namely, the one TRYING to get data from another application without 'permission') could get the data. Sortof like a buffer overflow. The memory is there, it's still part of the GC's memory pool, if someone can get around the 'security' they might as well have free access to that memory. |
| ||
| Just like how hacking the XBox works, softmods use the buffer overflow to crash the kernel and force it to load a patcher program which lets it run unsigned excutables. Commonly called the Font hack or Audio hack. Or you can buy a modchip.... @Noel, whats really the problem. If the memory is given back to the pool without being zero'd its still unlikely anyone can extract any amount of usuable data from it. Say some other function needs X amount of memory and takes it from the middle of the pool (the location of a large enough block maybe) the memory freed with your critical data has now got one great big gap of data missing from it -- pretty much making it redundant. I wouldnt say theres anything to worry about :/ |
| ||
| This is only a problem is the OS doesn't zero memory when a program requests it. (That's different than the app-level heap manager zeroing memory.) What happens under Windows, I believe, is that pages are automatically zeroed when requested from the OS, so no matter what was in there before, other applications can't see it. Again, this doesn't mean that blocks returned by "new" are zeroed, just that the initial heap starts out zeroed. |
   |