I can only second everything @erco77 said and may add that another reason of such sporadic issues can be any stale pointer, double free, access after free (delete) or something like that, be it in FLTK or in user code. If the OP was on Linux (but he's on Windows) I'd suggest using valgrind which can reveal issues that never do any harm - only after a runtime of 10 hours or so (by accident).

@chipnetics If you have any memory checker available I strongly recommend to use such tools to find any issues. If you find something in FLTK, please report; if you find something in your user code, please report as well and close this issue. If it's an option for you: I suggest to build your program on Linux and run it with valgrind to see if valgrind reports any issues. That's pretty easy if you can run your program on Linux.

@erco77 wrote:

Often when one gets problems like this, and adding printf() statements to the code magically "fixes" it, it's because the act of adding a print statement touches the source code file and causes it to be rebuilt, and /that's/ what fixes the problem.

Another reason why adding a printf() statement can change things: the memory layout of your app changes slightly and dereferencing a stale pointer suddenly doesn't do any harm. Also, newer systems have options to randomize load addresses which can make compiling an entirely unrelated module and linking the program change its behavior WRT dangling or stale pointers.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.