http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=831
Mike Caron <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Mike Caron <[email protected]> 2010-04-09 18:17:34 PDT --- So. I've been debugging for ~2-3 hours now. If there's one thing I've learned, this years, it's that I *really hate heap corruption*. Anyway. I'm working on a full fix. However, it involves substantial rewriting on my part. It will take a while to finish and test, so here's a workaround in the mean time: if doc->numAllocStrings = 0 then #if defined(__FB_WIN32__) doc-> strings = HeapAlloc(doc->heap, HEAP_ZERO_MEMORY, 16 * sizeof(string)) #else doc->strings = Callocate(16, sizeof(string)) #endif doc->numAllocStrings = 16 doc->numStrings = 1 doc->strings[0] = st return 1 else There's three 16s in that block. Change those to some higher number, like 64 or something (doesn't have to be a power of two). The problem is that when the string table grows past its initial size (as set in the snippet above), the new slots are not cleared properly. So, when RELOAD tries to use one of those slots, FB goes "oh hey, there's an existing string here, I'll just free it-asnkdfnskdbfa" and passes out on your carpet. However, the first n slots are automatically zeroed out, where n is the number you put in the snippet above. If the table is at least as big as the number of node names in the document, you'll never run into this bug. The fix I'm working on is to make the table resize properly (and, to mitigate this type of error in the future). -- Configure bugmail: http://rpg.hamsterrepublic.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
