1
votes

Note for the readers: this question is specific for Codename One and it specifically related to the crash protection.

There is a strange fact: I have an Android app on the store from several months with a lot of installations. Rarely (like two or three times on a month) I receive by email a crash protection report. This is the error:

[EDT] 0:0:0,88 - Exception: java.util.ConcurrentModificationException - null
java.util.ConcurrentModificationException
    at java.util.ArrayList$Itr.next(ArrayList.java:860)
    at com.codename1.impl.android.a.a(AndroidAsyncView.java:380)
    at com.codename1.impl.android.d.a(AndroidImplementation.java:1172)
    at com.codename1.impl.a.r(CodenameOneImplementation.java:610)
    at com.codename1.q.o.j(Display.java:1037)
    at com.codename1.q.o.i(Display.java:946)
    at com.codename1.q.ae.run(RunnableWrapper.java:120)
    at com.codename1.impl.b$1.run(CodenameOneThread.java:60)
    at java.lang.Thread.run(Thread.java:764)

Please note the time: [EDT] 0:0:0,88 means that the app was just started. I don't understand the meaning of this error, especially because there isn't any ArrayList in my code!

1

1 Answers

1
votes

TL;DR: It's OK, it's just for your records. If it causes a crash then we want to know it but it probably isn't the cause of a crash.

This exception happens because of the code from AndroidAsyncView. Specifically this loop https://github.com/codenameone/CodenameOne/blob/2f4c863bee9bfe8cbf210fb475a31bfa7a23cada/Ports/Android/src/com/codename1/impl/android/AndroidAsyncView.java#L384-L402

Notice that this is a race condition between the EDT and the main Android native thread. It shouldn't happen but it does. We can probably fix it by sprinkling synchronized all over the place but that would degrade performance. We chose to log it so we can keep track if it causes an actual crash. This condition might cause some rendering artifacts but those should be resolved automatically (see the repaint() call).