String Memory Management
BlitzMax Forums/BlitzMax Programming/String Memory Management
| ||
| Hi Blitzers, We're trying to track down some memory allocation/leak related issues in our game. It looks as though over the runtime of our app, we're generating over 800MB of string data (we make a lot of HTTP requests, caching the responses in strings). Aside from nulling out appropriate fields and making sure GCCollect() gets called, is there anything special I should know about managing string memory in BlitzMax? I took a peek at blitz_string.c and I noticed something rather peculiar:
//***** Note: Not called in THREADED mode.
static void bbStringFree( BBObject *o ){
#ifdef BB_GC_RC
BBString *str=(BBString*)o;
if( str==&bbEmptyString ){
str->refs=BBGC_MANYREFS;
return;
}
bbGCDeallocObject( str,sizeof(BBString)+str->length*sizeof(BBChar) );
#endif
}
Does this mean that BlitzMax strings will not get freed if running in Threaded mode? (note: our app is threaded :) ) If this is the case, how can you explicitly ensure the free-ing of a string? Thanks folks, Jason |
| ||
| Only one thing initially springs to my mind is : are you using 'String.ToCString()' anywhere at all?? That requires a call MemFree to free the memory assigned to the variable once you're finished with it. It's not needed using 'standard' Blitz strings though. |
| ||
| Hi Dave, I'm actually not using String.ToCString() at all. Just regular old strings. I store them in a map, then I ClearMap() and null out the map. I'm not sure if they ever truly get freed though. That exception in the C code snippet I showed above worries me. I ran a memory profiler on my app (Instruments, part of Apple Developer Tools), and it says my #1 source of memory allocations (that aren't freed) are from strings. In particular, it cites this stack flow: malloc heapAlloc allocMem bbGCAllocObject bbStringNew Can anyone confirm that despite the comments in bbStringFree, that Strings will still be automatically garbage collected if nulled out prior to a call to GCCollect()? Thanks, Jason |
| ||
| Maybe - this is just a shot in the dark - when a string is freed, Blitz actually keeps the memory lying around in a reserve pool, to reuse for the next string? Maybe you are referencing the strings in more than one place? If you assign a string variable, I don't know if it makes a copy, or if it references the original only, and only copies it if you make a change. So you could have the strings still referenced somewhere, even if the map is cleared out. In the same map, don't mix strings and non-strings in the keys or strings and non-strings in the values. Does this happen in non-threaded? Somebody offical will have to answer this I think. You could try sending a customer support message. They usually reply within a day or two. We should try to make a simple program that reproduces this error, adding lots of strings to a map in threaded mode and then clearing the map and seeing what happens. Last edited 2011 |
| ||
| Definitely sounds like something is holding a reference somewhere. I agree with Czar Flavius in that a little test app that does exactly the same as you are doing in your code to use as a 'test bench' is needed here. Then we can hone in on the problem. |
| ||
| Does the problem solved? |
   |