[
https://issues.apache.org/jira/browse/GROOVY-11775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18038287#comment-18038287
]
Björn Kautler commented on GROOVY-11775:
----------------------------------------
Unfortunately, stupid me did not preserve that state in some commit. :-(
I tried to reproduce the bad state in
https://github.com/Vampire/spock/tree/GROOVY-11775.
There are some tests failing due to other reasons and also some hangs, but that
is irrelevant for the issue I think.
I added at
https://github.com/Vampire/spock/blob/GROOVY-11775/spock-core/src/main/java/org/spockframework/runtime/SpecialMethodCallTarget.java#L52
an output of the identity hash code for the specification, the
specialmethocalltarget, and the specificationcontext.
If you execute the tests until it hangs, then copy out the `FOO` lines, sort
them, and search with the regex
{code}
FOO: s (\d+) / smct (\d+) / sc (\d+)[^a]+?FOO: s \1 / smct (?!\2)
{code}
then you will occasionally (every 2-4 runs) occasions of the regex like
{code}
FOO: s 1105428056 / smct 151693853 / sc 33598845
FOO: s 1105428056 / smct 151693853 / sc 33598845
FOO: s 1105428056 / smct 1983887302 / sc 1009257581
FOO: s 1105428056 / smct 1983887302 / sc 1009257581
FOO: s 1105428056 / smct 1983887302 / sc 1009257581
FOO: s 1105428056 / smct 1983887302 / sc 1009257581
FOO: s 1105428056 / smct 1983887302 / sc 1009257581
{code}
where the same specification instance had different specialmethodcalltargets
and thus specificationcontexts.
> Stateful runtime mixins sometimes do not work properly
> ------------------------------------------------------
>
> Key: GROOVY-11775
> URL: https://issues.apache.org/jira/browse/GROOVY-11775
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.26
> Reporter: Björn Kautler
> Priority: Major
>
> I have class {{A}} and class {{B}}.
> I {{mixin}} {{A}} to {{B}} using {{B.mixin(A)}}.
> {{A}} has a property {{X}}.
> Now I have a method {{M}} in a subclass of {{B}} which first calls a method
> {{N}} of {{A}}, then another method {{O}} of {{A}}.
> Both calls happen linearly, both happen on the same thread, yet occasionally
> the call to {{O}} hits a different instance of {{A}} than the call to {{N}}
> and thus {{N}} and {{O}} work on a different instance of the field in {{A}}.
> From a quick look at the code and debug, the problem might maybe be, that the
> {{MixinInMetaClass#managedIdentityConcurrentMap}} holds the {{B}} instances
> that serve as key in soft references. So maybe if the heap gets exhausted
> between calling {{N}} and {{O}}, the map entry is nuked by the garbage
> collector and thus the {{O}} call creates a new {{A}} instance.
> If this is the case (or actually whatever else causes what I see), stateful
> runtime mixins are quite flaky and should not be used unless this is fixed,
> as you cannot rely on the state. Actually, I was not able to knit an MCVE by
> intentionally triggering two OOME between the calls to {{N}} and {{O}}, so my
> suspicion about the cause might not be correct.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
