Infinite loop in java.util.HashMap

Question

I have very often blocked Vaadin code here, and I don’t know what the problem is:

Thread 7892: (state = IN_JAVA) - java.util.HashMap.getEntry(java.lang.Object) @bci=61, line=349 (Compiled frame; information may be imprecise) - java.util.HashMap.containsKey(java.lang.Object) @bci=2, line=335 (Compiled frame) - java.util.HashSet.contains(java.lang.Object) @bci=5, line=184 (Compiled frame) - com.vaadin.ui.Table.unregisterPropertiesAndComponents(java.util.HashSet, java.util.HashSet) @bci=85, line=1693 (Compiled frame) - com.vaadin.ui.Table.refreshRenderedCells() @bci=992, line=1641 (Compiled frame) - com.vaadin.ui.Table.valueChange(com.vaadin.data.Property$ValueChangeEvent) @bci=23, line=2897 (Compiled frame) - com.vaadin.data.util.IndexedContainer.firePropertyValueChange(com.vaadin.data.util.IndexedContainer$IndexedContainerProperty) @bci=140, line=553 (Compiled frame) - com.vaadin.data.util.IndexedContainer.access$1000(com.vaadin.data.util.IndexedContainer, com.vaadin.data.util.IndexedContainer$IndexedContainerProperty) @bci=2, line=64 (Compiled frame) - com.vaadin.data.util.IndexedContainer$IndexedContainerProperty.setValue(java.lang.Object) @bci=202, line=915 (Compiled frame) - com.aimprosoft.wavilon.backgroundthreads.ChangeCdrThread.insertNewPersonIntoTable(com.aimprosoft.wavilon.model.Person, com.vaadin.ui.HorizontalLayout, com.aimprosoft.wavilon.ui.menuitems.CallContent, com.vaadin.ui.Table) @bci=924, line=208 (Interpreted frame) - com.aimprosoft.wavilon.backgroundthreads.ChangeCdrThread$RepaintTableThread.run() @bci=622, line=446 (Compiled frame) 

Can anyone suggest any way to further debug this problem? The problem is very rare and quite difficult to reproduce.

Answer 1

Based on where it is in the code, the only explanation I can come up with is that there are several threads that access the TG40 and update it without proper synchronization. This can damage map data structures and can lead to an endless loop.

I can't think of any other reason why java.util.HashMap.getEntry would lock. It does not perform any synchronization or I / O.

---

Roland Illig comments:

The line number does indicate that the code hangs in one of the e = e.next .

This confirms my hypothesis. A specific sequence of operations on a hash table performed by two (or more) threads led to the creation of a loop / loop in one of the hash chains. This damage occurred due to insufficient synchronization between threads performing operations. This happens very rarely, but as soon as this happens, corruption will not disappear.

Without delving into the Vaadin source code, I cannot say for sure whether this is a Vaadin error, or an error in how you use Vaadin. Any explanation is believable.

UPDATE

Based on this article (provided in the comment below), I would say that, most likely, this is a problem in how your application is synchronized (or not).

Answer 2

So, you actually see here a thread going into an infinite loop evaluating e = e.next

In fact

e.next == e

This happens when you put multiple threads into the HashMap during table restructuring.

Take a look at this link for more information.

Excellent race condition

To solve this problem, use either Collections.synchronizedMap or ConcurrentHashMap . I suggest the latter.

Answer 3

Is the background thread synchronized in the application instance when the component changes? If not, then this is your problem.