Runs fine on OF 0.9.8, but dies on OF 0.10/0.11! What to do?


I’m having a puzzling and extremely annoying issue, which of course any developpers nightmare.
A project written on OF (small video game), works runs without any issues for days and weeks on

OF 0.9.8 + Raspberry PI3 + Jesse

however the exact same code compiled hangs after approximately 20 minutes on

OF 0.11.0 + Raspberry PI3 B+ Buster
OF 0.10.0 + Raspberry PI3 B+ Stretch

In both cases it’s running idle without any user interaction. By idle I mean that there are just couple simple sprites floating across the screen and simple timers. All graphical elements have been preloaded and it’s just waiting for input.

I’m very puzzled. Tried to monitor memory usage, but I don’t see any leaks. But it just hangs to the point where it needs to be killed with CTRL-C. And curiously afterwards it won’t run again and OS needs to be rebooted.

So this is a question for OF developpers - is there anything you can think of, that have changed in terms of memory management between OF 0.9.8 and up ?

Is there any tools to monitor what’s going on ?

I still suspect memory leak, but how to catch it ?

I’m very determined to make this code run on PI3 B+ and have spend already two days on this. But it still hangs… and still runs fin on PI3/Jesse.


here is my update() code

void ofApp::update(){

// process background
	mySun.draw(sunPos.x, sunPos.y);
	myClouds[0]->getCloud().draw(myClouds[0]->getX(), myClouds[0]->getY());
	myClouds[1]->getCloud().draw(myClouds[1]->getX(), myClouds[1]->getY());


if (ofGetElapsedTimeMillis() - crowDelayZeroTime > crowDelayTime) {
	if (ofRandom(0,100) > 30);

	crowDelayZeroTime = ofGetElapsedTimeMillis();

and here is my draw()

void ofApp::draw()

and setup()

void ofApp::setup(){
fbo.allocate(ofGetWidth(), ofGetHeight());
fbo_ul.allocate(ofGetWidth(), ofGetHeight());
fbo_ol.allocate(ofGetWidth(), ofGetHeight());
myForest->render(&fbo_ul, &fbo_ol);

A couple of possible things come to mind:

  1. There is some sort of energy saver setting that is kicking in after twenty minutes or so, that somehow locks the app.
  2. The sound player is leaking memory on each play which eventually locks the app.
  3. What is imgCounter ? that is an index for array access which could be accessing out of bounds data.

Can you post the full code to a gist?


Hello Theo,

Thanks for your answer.

  1. could be, but it’s not always 20 minutes.
  2. wow… not good, however I disabled it for testing…
  3. No, it’s not out of bound. Just some element that jumps every now and then. Preloaded images. And no segmentation fault or anything, that should’ve been the case.

I probably need to test the thing with different power supply. I’m not even sure if it’s hardware or software issue, since I use different RPI. What a headache! )

Let me check and get back to you.


ps. is there any reason why programm won’t start again ? It looks like it can’t initialize video system, it says EWGL, creating render … and doesn’t go further. only reboot…

Hello Theo,

Ok, I did run more tests. Different board, different power supply. Same result…
I have disabled WIFI, bluetooth and swap, but didn’t make a difference.

So two questions:

  1. Which example that comes with OF you suggest I can use as a test case. I leave it running and see if it hangs as well. Something with GL and sprites maybe ?

  2. I was thinking to write log - dump some sort of internal OF information to a log to try to see what’s going on. Is there an API call you can suggest me to use ?

Thanks much

Ok, so on

RPI3 + Jesse + OF 0.9.8 my code runs straight 48 hours without a glitch

RPI3B+ Stretch + OF0.10.0 same code hangs dead after 20-40 minutes

If you guys have no idea, my only solution is to go with RPI3 and old version of OF.
This is quite annoying and very frustrating, but I just don’t have any tools or ideas on how to deal with this.



Apologies for all the issues.
I only have a PI 4 here, but I will give it a go today and see how long it runs an example without issue.

Are you using your PI with X windows or just from the command line?


Well, forget about it.
I spent another half a day… setup a script which dumps GPU memory info into a file at regular basis.
There is a “heap corruption detected” error at the end, which is probably why the whole thing freezes.
Tried to isolate/disable different parts of code, but this is so time consuming, as it hangs after about 35 minutes.

So I gave up and ordered 5 Raspeberry PIs 3B, although I have plenty of them them in B+ version.
It just not worth wasting any more time on this. Downgrade!

Thanks anyway.


ps. running from command-line… it’s an interactive installation, so no keyboard, nothing. it just boots up directly into OF app.


Just to let you know that for me on RPI 4 with the GLFW window running from the X environment the polygon example runs for over an hour without issue.

You could try the use legacy in the make file for 0.11.0 ( if you aren’t already ). With that set it should function the same as 0.9.8. To enable the legacy build comment out this line:

Sorry that it has been such a nightmare.

Yes, the examples from OF run just fine for me as well.

I already tried the 0.11.0 and found the Legacy trick )

Still hangs.

I suspect that something got more strict in OF 0.10.0 in terms of memory management. And there is something in my code that I can get away with in OF 0.9.8, but leads to problem in higher versions.

Since I have a working combo (RPI3+Jesse+OF0.9.8), it’s really not worth investigating any further.

But being a developer myself of course it irritates me, that despite all the affords I didn’t manage to find the root cause and make it work )