Open RFO-BASIC opened 12 years ago
Values of static variables can persist across what looks like new invocations of an app, because in Android the app may not really have died. That means an uninitialized static variable can bite you harder in Android than in most environments. But BASIC! is really good about initializing everything. Bewildered, I am.
Run does not depend upon those static variables being cleared each time Run is executed. Run uses the InitVars() method to properly set the variables. GRopen is one of those variables that gets initialized. So, in the above example, GRopen would have been set false in onCreate. This should have prevented execute_gr_save() from being called.
Often in those index out of bounds situations that I described above the stack dump will tell me that the array list or string length is zero but the invalid index is > 0. So, in those cases, the still running program had its variables reset while running.
I do know that Android takes it sweet time to call onDestroy after calling finish. Sometimes if another run can be started before the onDestroy gets called. The was a time where I was enforcing a 10 second delay between runs. That really did not help.
Here are the important lines from the Stack Trace:
Caused by: android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views. at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:4267) at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:842) at android.view.View.requestLayout(View.java:12815) at android.view.View.setLayoutParams(View.java:8358) at android.view.WindowManagerImpl.updateViewLayout(WindowManagerImpl.java:312) at android.view.WindowManagerImpl$CompatModeWrapper.updateViewLayout(WindowManagerImpl.java:145) at android.app.Activity.onWindowAttributesChanged(Activity.java:2235) at android.view.Window.setAttributes(Window.java:785) at com.rfo.basic.GR$DrawView.onDraw(GR.java:418) at android.view.View.draw(View.java:11118) at android.view.View.buildDrawingCache(View.java:10835) at android.view.View.buildDrawingCache(View.java:10675) at com.rfo.basic.Run.execute_gr_save(Run.java:11766) at com.rfo.basic.Run.executeGR(Run.java:9982) at com.rfo.basic.Run.StatementExecuter(Run.java:2902) at com.rfo.basic.Run.access$4(Run.java:2738) at com.rfo.basic.Run$Background.RunLoop(Run.java:1654) at com.rfo.basic.Run$Background.doInBackground(Run.java:1599) at com.rfo.basic.Run$Background.doInBackground(Run.java:1)
What happened: Run started The first command executed was gr.save. execute_gr_save() should not have been called because graphics was not opened. It should not have been called but it was. It was and it caused a crash.
I often see crash reports like this. A statement crashes in an impossible way. One thing I often see are cases where there is an "index out bound" error but two or three statements before the line that crashed, the index was verified to be in bound.
It is like Run is continuing to run a previous program rather that starting with a fresh program.
Even stranger, this user created this exact same crash four times in a one hour period.
I am hoping that some fresh eyes and ideas can help to solve the mystery.