[
https://issues.apache.org/jira/browse/GROOVY-8113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18135488#comment-18135488
]
ASF GitHub Bot commented on GROOVY-8113:
----------------------------------------
testlens-app[bot] commented on PR #3109:
URL: https://github.com/apache/groovy/pull/3109#issuecomment-6536459006
## 🚨 TestLens detected 1 failed test 🚨
### Test Summary
> [!TIP]
> Inspect all details with the [TestLens
CLI](https://testlens.app/docs/features/cli): `testlens pr 3109`
#### [Build and test / lts \(21,
ubuntu-latest\)](https://github.com/apache/groovy/actions/runs/41147623618/job/124376332555?pr=3109)
> :test
| Test | Runs | Flakiness |
|---|---|--:|
| MethodReferenceTest >
testMethodReferencesInStaticAndDefaultMethodsOfInterface\(\) | ❌ | 0% 🟢 |
🏷️ Commit: 6f811f0be598dd22c19cec12045568321cc609d4
▶️ Tests: 67917 executed
🟡 Checks: 12/25 completed
### Test Failures
<details><summary><strong>MethodReferenceTest >
testMethodReferencesInStaticAndDefaultMethodsOfInterface()</strong> (:test in
<a
href="https://github.com/apache/groovy/actions/runs/41147623618/job/124376332555?pr=3109";>Build
and test / lts (21, ubuntu-latest)</a>)</summary>
```
java.lang.ClassFormatError: Method gstring$I$ctorRef$make$0$1 in class I has
illegal modifiers: 0x101A
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1027)
at
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
at groovy.lang.GroovyClassLoader.access$000(GroovyClassLoader.java:91)
at
groovy.lang.GroovyClassLoader$ClassCollector.createClass(GroovyClassLoader.java:1465)
at groovy.lang.GroovyClassLoader.collect(GroovyClassLoader.java:292)
at
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:448)
at
groovy.lang.GroovyClassLoader.lambda$parseClass$2(GroovyClassLoader.java:386)
at
org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:143)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:386)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:664)
at groovy.lang.GroovyShell.parse(GroovyShell.java:677)
at groovy.lang.GroovyShell.parse(GroovyShell.java:689)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:551)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:587)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:571)
at groovy.test.GroovyAssert.assertScript(GroovyAssert.java:107)
at
groovy.transform.stc.MethodReferenceTest.testMethodReferencesInStaticAndDefaultMethodsOfInterface(MethodReferenceTest.groovy:1613)
```
</details>
### Rerun Controls
> [!NOTE]
> Checks are currently running using the configuration below.
Select tests to mute in this pull request:
🔲 MethodReferenceTest >
testMethodReferencesInStaticAndDefaultMethodsOfInterface\(\) <!
> Groovy script/template engine produce memory leak
> --------------------------------------------------
>
> Key: GROOVY-8113
> URL: https://issues.apache.org/jira/browse/GROOVY-8113
> Project: Groovy
> Issue Type: Bug
> Components: groovy-templates, GroovyScriptEngine
> Affects Versions: 2.4.8
> Environment: Groovy 2.4.8, Oracle Java JDK 8u121
> Reporter: Artyom Kravchenko
> Priority: Critical
> Attachments: merged_path.png, object_explorer.png
>
>
> There is a simple way to produce OutOfMemoryException if run infinite
> numbers of groovy scripts or evaluate groovy templates.
> Simple test to reproduce a memory leak(run groovy script and make template
> inside the script):
> set max heap size: -Xmx7m
> {code:java}
> import javax.script.*;
> import java.util.HashMap;
> import java.util.Map;
> public class OutOfMemoryTest {
> private static String TEMPLATE = "Dear ${fullName} please go away at
> ${time}";
> private static String SCRIPT = "def run(args) {\n" +
> "def bindings = ['fullName' : 'Ali Baba', 'time' : new Date()]\n"
> +
> "println
> args.templateEngine.createTemplate(args.template).make(bindings).toString()\n"
> +
> "}";
> public static void main(String... args) {
> //
> GroovySystem.getMetaClassRegistry().getMetaClassCreationHandler().setDisableCustomMetaClassLookup(true);
> while(true) {
> ScriptEngineManager engineManager = new ScriptEngineManager();
> ScriptEngine engine = engineManager.getEngineByName("groovy");
> try {
> engine.eval(SCRIPT);
> } catch (ScriptException e) {
> throw new RuntimeException(e);
> }
> groovy.text.SimpleTemplateEngine templateEngine = new
> groovy.text.SimpleTemplateEngine();
> Invocable inv = (Invocable) engine;
> Map<String, Object> params = new HashMap<>();
> params.put("template", TEMPLATE);
> params.put("templateEngine", templateEngine);
> Object[] runArgs = { params };
> try {
> inv.invokeFunction("run", runArgs);
> } catch (ScriptException | NoSuchMethodException e) {
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> The main cause of issue is Java class loader. Two instances:
> sun.misc.Launcher.AppClassLoader and sun.misc.Launcher.ExtClassLoader
> (parent for first one), each of them has a strong reference:
> {code:java}
> ConcurrentHashMap<String, Object> parallelLockMap
> {code}
> It collects all loaded classes (and never releases their) for application
> including newly created script/template classes.
> The main reason of introduction of this reference described here:
> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
> For each iteration of my test I see that parallelLockMap grows with 6 new
> entries:
> {code:java}
> groovy.runtime.metaclass.Script94MetaClass
> Script94BeanInfo
> Script94Customizer
> groovy.runtime.metaclass.SimpleTemplateScript94MetaClass
> SimpleTemplateScript94BeanInfo
> SimpleTemplateScript94Customizer
> {code}
> See memory snapshots(attached): objects_explorer, merged_path.
> I have found a partial solution of the issue, if I add this code line to my
> test:
> {code:java}
>
> GroovySystem.getMetaClassRegistry().getMetaClassCreationHandler().setDisableCustomMetaClassLookup(true);
> {code}
> I see that classes like:
> {code:java}
> groovy.runtime.metaclass.Script94MetaClass
> groovy.runtime.metaclass.SimpleTemplateScript94MetaClass
> {code}
> goes away (groovy engine don't ask ClassLoader to find this classes on class
> path therefore such classes are not collected by ClassLoader) but classes
> like
> {code:java}
> Script94BeanInfo
> Script94Customizer
> SimpleTemplateScript94BeanInfo
> SimpleTemplateScript94Customizer
> {code}
> still has affect on memory.
> Dear developers, could you please point me any advice/workarounds for this
> issue. It will be fine to get rig this issue in future releases.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
