What to look for if processing sketch freezes occassionally but doesn't produce an error message?

r3dm

Hey everyone, not sure how to fully describe this, but the problem I'm running into is that a cyclical sketch is supposed to run 300 times then pause, but sometimes the sketch freezes without showing an error message. To add to the confusion, what I'm seeing on-screen in the run window doesn't seem to match the println commands that are coming out of the console during the crash. Does this sound familiar to anyone?

The code is pretty long so I won't post it here, but if anyone's run into similar problems with more intensive processing sketches (this one is trying to simulate city growth using voxels), or has any troubleshooting advice that would be very helpful! Could it be running out of allocated memory for processing or something like that, causing it to freeze without causing an error?

GoToLoop

https://StackOverflow.com/questions/16695874/why-does-the-jvm-full-gc-need-to-stop-the-world

http://www.Cubrid.org/blog/understanding-java-garbage-collection

r3dm

Ah thank you! based on these articles, it looks like you're suggesting the symptoms i'm describing are a stop-the-world pause caused by garbage collection, which makes sense given the number of objects I'm creating and the length the program has been running, but I didn't know enough about them to diagnose that -- do you know because it froze without causing an error, or because of the run screen's view not matching the console?

Since I don't need the program to run in real time, it looks like I can just wait it out and allow the garbage collection to run and continue the program after?

r3dm

I just checked the .png files I was exporting, it looks like the program ran for 2 hours as expected, but then froze for 5 hours -- which seems like a long time for a garbage collection process?

GoToLoop

• GC was just a guess. 5 hours can't be GC. Dunno what it is though... 8-|
• However, be careful w/ too many println() within a short time between them. L-)
• Too many sequential println() surely freeze a sketch! :-SS

r3dm

good point on the println() ! I was using them to diagnose a problem, but maybe i just created another one in its place... thanks for your input! going to try re-running without the println() / exporting to application and running and see if i'm successful

GoToLoop

• In order to avoid massive amounts of println() in too short time between each of them, you may place a limiting condition for them to happen.
• For example, if (frameCount % 60 == 0) { println(); } limits its println() to happen once per second.
• By default, draw() is called back at about 60 FPS. And frameCount stores how many that happened.
• % 120 would lengthen it to once per 2 seconds. While % 30 to once per half a second.

GoToLoop

For more professional logging w/o freezing, you may choose Java's package java.util.logging:

1. http://Docs.Oracle.com/javase/8/docs/api/java/util/logging/package-summary.html
2. http://JavaRevisited.Blogspot.com/2011/05/top-10-tips-on-logging-in-java.html

Disclaimer: Never used the Logger class though. Or any logging solution. :(|)

Alternatively, or as an addition too, you can use assert in order to interrupt the sketch if its condition turns out false: :-\"
http://JavareVisited.Blogspot.com/2012/01/what-is-assertion-in-java-java.html

r3dm

After some further debugging I think it probably was the println() I added combined with just too many commands being run per frame, getting rid of those seemed to make it run smoother! thanks for the input! Also managed to find an array index out of bounds in the proces.

samrogerwilliams

Well you can refer below resource for detailed explanation on java garbage collection, http://www.flowerbrackets.com/java-garbage-collection/

jeremydouglass

@r3dm -- re:

After some further debugging I think it probably was the println() I added combined with just too many commands being run per frame, getting rid of those seemed to make it run smoother! thanks for the input! Also managed to find an array index out of bounds in the process.

That sounds right. From the reference:

• https://processing.org/reference/println_.html

Note that the console is relatively slow. It works well for occasional messages, but does not support high-speed, real-time output (such as at 60 frames per second). It should also be noted, that a println() within a for loop can sometimes lock up the program, and cause the sketch to freeze.

koogs

that's been fixed recently. try updating your processing.

jeremydouglass

@koogs -- Interesting. Should a change be submitted to the public reference to remove that warning language?