After chasing my tail for days over incomplete OLED displays, I finally discover the problem was a low memory issue.
At the bottom of the IDE, there are tally's of program and dynamic memory usage... 79% and 45% respectively for my sketch. I checked these periodically and thought I had plenty of 'headroom'. I didn't!
After searching for ways to reduce memory, I managed to lower my program and dynamic memories usage a few percent. Then ... WaLa, my sketch runs flawlessly.
Just how accurate are the IDE memory tallies, and what are the values one should not exceed ??
In this sort of situation, it's only the "dynamic memory" (SRAM) usage that you need to be concerned with. As far as "program memory" (flash) goes, you can use as much as you like as long as you don't go over 100%.
The important thing to notice is that the IDE isn not reporting "dynamic memory". It's reporting the dynamic memory used by global variables. It is not reporting the dynamic memory used by local variables. The number n you see in the "leaving n bytes for local variables" is crucial. Even though the IDE will show a warning at 75%, you can only know how much headroom is needed by analyzing the program's memory usage for local variables, which changes while the program runs.
@pert gave the explanation regarding the memory usage report.
As you did not show your code, one guess would be the use of String objects (capital S) which don't count in the dynamic memory reporting. And can leave holes in your memory if used incorrectly.
Other possible cause is writing outside the boundaries of arrays. The result is unpredictable; e.g. removing or adding a single line of unrelated code can make the program crash or seemingly work.
Passing objects as arguments to functions instead of references or pointers to those objects can pose another issue.