ConcurrentModificationException when displaying OBD data screen

[LowLevelJet]

I am not sure it's relevant to this issue but for completeness sake: the car I have this issue on is a 2009 Hyundai Sonata GLS. The engine is started before I plug in the adapter. This adapter (a Bluetooth ELM, a clone I suppose though I don't know) has been used successfully with this car as well as a 2003 Pontiac Grand Am with another app that only retrieves trouble codes.

After connecting to the ECU, I can access the "OBD Vehicle Info" screen. It loads and is populated with the correct information (the VIN is correct, etc.). If I select "OBD Data" the application crashes. In logcat, I see this:

02-15 10:29:13.240 16008 16008 E AndroidRuntime: FATAL EXCEPTION: main 02-15 10:29:13.240 16008 16008 E AndroidRuntime: java.util.ConcurrentModificationException 02-15 10:29:13.240 16008 16008 E AndroidRuntime: at java.util.HashMap$HashIterator.nextEntry(HashMap.java:792) 02-15 10:29:13.240 16008 16008 E AndroidRuntime: at java.util.HashMap$ValueIterator.next(HashMap.java:824) 02-15 10:29:13.240 16008 16008 E AndroidRuntime: at com.fr3ts0n.ecu.gui.androbd.ObdItemAdapter.addAllDataSeries(ObdItemAdapter.java:231) 02-15 10:29:13.240 16008 16008 E AndroidRuntime: at com.fr3ts0n.ecu.gui.androbd.ObdItemAdapter.setPvList(ObdItemAdapter.java:97) 02-15 10:29:13.240 16008 16008 E AndroidRuntime: at com.fr3ts0n.ecu.gui.androbd.MainActivity$2.handleMessage(MainActivity.java:373) 02-15 10:29:13.240 16008 16008 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:99) 02-15 10:29:13.240 16008 16008 E AndroidRuntime: at android.os.Looper.loop(Looper.java:137) 02-15 10:29:13.240 16008 16008 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:5227) 02-15 10:29:13.240 16008 16008 E AndroidRuntime: at java.lang.reflect.Method.invokeNative(Native Method) 02-15 10:29:13.240 16008 16008 E AndroidRuntime: at java.lang.reflect.Method.invoke(Method.java:511) 02-15 10:29:13.240 16008 16008 E AndroidRuntime: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:795) 02-15 10:29:13.240 16008 16008 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:562) 02-15 10:29:13.240 16008 16008 E AndroidRuntime: at dalvik.system.NativeStart.main(Native Method)

[fr3ts0n]

Thanks for your report, Could you please repeat your test with AndrOBD logging level set to DEBUG or TRACE and post the AndrOBD.log file. This would help me a lot to find out what happened in OBD communication that led to this issue. Thank you

[LowLevelJet]

I have a log file at DEBUG level, based on time stamps it appears to be missing this application run. I tried again after I arrived where I was going and then a second time before I left there, these two are in the log. I will try again tomorrow and be sure to save the log if it crashes again.

Here is a paste link since the log is so large - http://pastebin.com/fvYfXq5z

I will follow up with a log including this crash when I get a chance to reproduce it.

[LowLevelJet]

I am having great difficulty getting the application to connect. Occasionally it connects (and this issue shows up) but more often than not, on selecting a screen (OBD Vehicle Info, Data, ...) the dongle simply disconnects. This is probably a separate issue — I know that many or even most applications that I have tried to use with this dongle exhibit this issue. I think the issue is that this ELM clone lacks any kind of serial buffer. Android has no API for controlling Bluetooth baud rate (even though it is required by RFCOMM), so the 'solution' is to Thread.sleep(50) or similar between sending each character to the dongle. I can open a separate issue for this if you are willing to implement this change, but for now, I will have difficulty getting the AndrOBD log you need since it's hit or miss whether the application works at all.

[fr3ts0n]

Looking at your previous log file I agree: Your Adapter shows a very strange behaviour:

• no indication of adapter type after reset
  • This is required to trigger setting all init commands to TX queue
• no prompt char ">" to indicate readiness for new commands
  • As a result this leads to incomplete initialisaton of the adapter, since the init sequence triggers on ">" to issue next init command.

I don't know if this is a matter of configuration on your adapter, or if this adapter just is not compatible.

Please could you send me a link to this adapter, to find out if there may be a chance to configure?

Other than that, I don't see a real chance to solve this by adding wait cycles into the communication. This would maximally be a very poor workaround for a extremely poor adapter implementation.

[LowLevelJet]

https://www.amazon.com/Professional-Diagnostic-ELM327-Bluetooth-Interface/dp/B00EQ57BE8/ref=sr_1_8?ie=UTF8&qid=1487459214&sr=8-8&keywords=elm+obd+ii+bluetooth This looks similar, based on the picture.

But if you are not willing to implement baud rate control emulation, I suppose you should close this bug. I'm not willing to spend money on a more expensive dongle when I know this one works fine.

[fr3ts0n]

Good that you re-opened the issue, because I am still not done with it yet. ;-)

First of all, it shows a real bug in the SW (from your initial post) which should not happen at all, and I really want to find out what causes this concurrent modification.

2nd: If we can improve the app to support more adapters, -> it improves the app!

I just need to find the right spot in the architecture where- and how to implement this without breaking anything else.

To me it looks like this (virtual) baud rate limitation should be implemented for bluetooth and wifi adapters, since the base problem is the same on both media.

Pls give me some more time to think about it.

[fr3ts0n]

I have created a new version for your tests: AndrOBD_V1.4.7_Test

Changes:

Changed the central StreamHandler to send everything through a BufferedWriter with a buffer size of 1 byte. I hope this forces a BT flush with every TX char. I have tested it with my adapter on my car and did not find anything broken.

Lets see if this helps for your adapter ...

[fr3ts0n]

Any news???

[fr3ts0n]

Any test results?

[fr3ts0n]

Fix released with V1.4.7