Confirmed that this does not reproduce on amd64. Perhaps the stack size could be manually cranked up? javac -source 1.8 -target 1.8 -d target/test-classes -encoding UTF-8 -classpath target/test-classes:json.jar:/var/tmp/portage/dev-java/json-20240205-r1/distdir/json-path-2.9.0.jar:/usr/share/asm-9/lib/asm.jar:/usr/share/asm-9/lib/asm-tree.jar:/usr/share/asm-9/lib/asm-analysis.jar:/usr/share/asm-9/lib/asm-commons.jar:/usr/share/asm-9/lib/asm-util.jar:/usr/share/json-smart-2/lib/accessors-smart.jar:/usr/share/json-smart-2/lib/json-smart.jar:/usr/share/junit-4/lib/junit.jar:/usr/share/hamcrest-core-1.3/lib/hamcrest-core.jar:/usr/share/mockito-4/lib/mockito.jar:/usr/share/asm-9/lib/asm.jar:/usr/share/asm-9/lib/asm-tree.jar:/usr/share/asm-9/lib/asm-analysis.jar:/usr/share/asm-9/lib/asm-commons.jar:/usr/share/asm-9/lib/asm-util.jar:/usr/share/byte-buddy/lib/byte-buddy-agent.jar:/usr/share/byte-buddy/lib/byte-buddy.jar:/usr/share/objenesis/lib/objenesis.jar:/usr/share/slf4j-api/lib/slf4j-api.jar @test_sources.lst warning: [options] bootstrap class path not set in conjunction with -source 8 1 warning The system is out of resources. Consult the following stack trace for details. java.lang.StackOverflowError at jdk.compiler/com.sun.tools.javac.code.Types$MembersClosureCache.visitClassType(Types.java:3057) at jdk.compiler/com.sun.tools.javac.code.Types$MembersClosureCache.visitClassType(Types.java:3009) at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:1011) at jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4900) at jdk.compiler/com.sun.tools.javac.code.Types.membersClosure(Types.java:3092) at jdk.compiler/com.sun.tools.javac.code.Types$ImplementationCache.get(Types.java:2966) at jdk.compiler/com.sun.tools.javac.code.Types.implementation(Types.java:3004) at jdk.compiler/com.sun.tools.javac.code.Symbol$MethodSymbol.implementation(Symbol.java:2175) at jdk.compiler/com.sun.tools.javac.code.Symbol$MethodSymbol.implementation(Symbol.java:2168) at jdk.compiler/com.sun.tools.javac.comp.Resolve.notOverriddenIn(Resolve.java:471) at jdk.compiler/com.sun.tools.javac.comp.Resolve.selectBest(Resolve.java:1572) at jdk.compiler/com.sun.tools.javac.comp.Resolve.findMethodInScope(Resolve.java:1788) at jdk.compiler/com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1858) at jdk.compiler/com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1832) at jdk.compiler/com.sun.tools.javac.comp.Resolve$11.doLookup(Resolve.java:2737) at jdk.compiler/com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(Resolve.java:3454) at jdk.compiler/com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3706) at jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(Resolve.java:2734) at jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(Resolve.java:2728) at jdk.compiler/com.sun.tools.javac.comp.Attr.selectSym(Attr.java:4418) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:4298) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2450) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:2568) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1797) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:4270) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2450) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:2568) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1797) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:4270) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2450) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:2568) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1797) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:4270) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2450) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:2568) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1797) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:4270) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2450) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:2568) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1797) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:4270) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2450) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:2568) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1797) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:4270) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2450) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:2568) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1797) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:4270) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2450) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:2568) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1797) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:4270) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2450) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:2568) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1797) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:4270) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2450) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:2568) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1797) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:4270) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2450) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:2568) ... Reproducible: Always
Created attachment 891802 [details] build.log and emerge --info
(In reply to matoro from comment #0) > Confirmed that this does not reproduce on amd64. Perhaps the stack size > could be manually cranked up? > [...] That's what we did in commit https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=64ff94e3095b0f975876e4dfeeddf5ee4865b5f7 which was obviously wrong.
I think we should copy the CHECKREQS_MEMORY syntax which is used in dev-java/bcprov
matoro, Thanks for verifying the error doesn't occur on amd64. Could you please help me and also verify it's not a Gentoo error? The procedure would be as simple as: 1. emerge maven-bin 2. cd /var/db/repos/gentoo/dev-java/json 3. ebuild json-20240205-r1 clean unpack 4. pushd /var/tmp/portage/dev-java/json-20240205-r1/work/JSON-java-20240205/ 5. mvn test
Created attachment 891918 [details] maven log Yes, still triggers outside portage with "mvn test".
Upstream bug https://github.com/stleary/JSON-java/issues/890
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2ba1910ac10793e5fb6e6644eab44624a2af52b0 commit 2ba1910ac10793e5fb6e6644eab44624a2af52b0 Author: Volkmar W. Pogatzki <gentoo@pogatzki.net> AuthorDate: 2024-07-29 09:35:05 +0000 Commit: Arthur Zamarin <arthurzam@gentoo.org> CommitDate: 2024-07-29 15:14:55 +0000 dev-java/json: unkeyword 20231013-r1 for x86 Closes: https://bugs.gentoo.org/930723 Closes: https://bugs.gentoo.org/926808 Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net> Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> dev-java/json/json-20231013-r1.ebuild | 2 +- dev-java/json/json-20240205-r1.ebuild | 2 +- dev-java/json/json-20240303.ebuild | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
