StackOverflowError on HashMap.hashCode() due to self reference

[Florian Weimer]

On 07/17/2015 09:25 PM, Louis Wasserman wrote:
> The Javadoc of Map already specifies:
> 
>> > Note: great care must be exercised if mutable objects are used as map
> keys. The behavior of a map is not specified if the value of an object is
> changed in a manner that affects equals comparisons while the object is a
> key in the map. *A special case of this prohibition is that it is not
> permissible for a map to contain itself as a key. While it is permissible
> for a map to contain itself as a value, extreme caution is advised:
> the **equals and hashCode methods
> are no longer well defined on such a map.*

The problematic entry had the self-reference in the value, not the key,
so this explanation does not really apply here.

But java.util.Collections does mention this problem:

“
Some collection operations which perform recursive traversal of the
collection may fail with an exception for self-referential instances
where the collection directly or indirectly contains itself. This
includes the clone(), equals(), hashCode() and toString() methods.
Implementations may optionally handle the self-referential scenario,
however most current implementations do not do so.
”

-- 
Florian Weimer / Red Hat Product Security