Have been reading DrMemory. However, this isnt' unusual for MS release builds in particular.
As I mentioned and you're obviously aware, why DON'T you used calloc internally? This is running rock solid with that 1 change in ft_alloc() I consider this fixed until/unless something else goes boom (shouldn't be set to 0 by default) But this runs solid in debug and now release with calloc in ft_alloc() -----Original Message----- From: werner.lemb...@gmx.de [mailto:werner.lemb...@gmx.de] On Behalf Of Werner LEMBERG Sent: Saturday, March 22, 2014 10:12 AM To: ch...@burfoots.com Subject: Re: [ft-devel] Stack Overflow ? > So I analyzed how the memory was allocated. I realized that EVERYTHING > was alloced from ft_alloc(memory, size) so I substituted > ft_scalloc(size,1) for ft_smalloc ... Presto bingo - everything seems > to be JUST FINE This essentially only hides a bug – if there is a bug. > It's the Microsoft (and sometimes Linux or Mac) uninitialized memory > error. FreeType has been stress-tested a lot with very picky compilers that find uninitialized memory issues at runtime. No issues are known currently. I *really* doubt that this is an issue here; it must be something else. > THIS is one of the dirtiest issues in release builds with Visual > Studio - indeterminate state of allocated memory AND can be especially > insidious when it's a variable on the stack What about using Dr. Memory to get more information? I've never tried it, but it seems to be an equivalent to `valgrind' on GNU/Linux... http://drmemory.org Werner _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel