>> Of course, loading this large data buffer probably does change the >> alignment in RAM of various other objects, so I there is a leak >> somewhere else, that might expose it. > > Exactly! The OP's problem could be as simple as a char string pointer or > the like going out of scope but not always being caught as an error. > That's what it was in my case -- the initial error didn't appear to be > caused by the call to label(), but happened some time later. Another > clue was that the "point of error" seemed to move around.
Oh yes - absolute classic and hard to debug... One thought (Loic) if you have access to a linux box and/or a mac, it's always worth giving the code a spin on the other platforms, simply because they have different memory management and allocation schemes, so that if there is some problem they tend to reveal it in different ways, and that can help pin it down. Back in the day, I had a block of code that had a nasty allocation bug in it that I ran for years on WinNT with no problems at all, died straight off when I ported it to linux - really obvious bug once I looked for it, too. FWIW, I find that OSX's memory management is very good at telling me when I go wrong, and so far it's been right every time! -- Ian _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
