Bug ID: JDK-8315640 Shenandoah: Stack overflow with C1 in java/net/spi/InetAddressResolverProvider/RuntimePermissionTest

Type: Bug
Component: hotspot
Sub-Component: gc
Affected Version: 22

Priority: P4
Status: Resolved
Resolution: Duplicate

Submitted: 2023-09-04
Updated: 2023-10-06
Resolved: 2023-09-12

$ CONF=linux-x86_64-server-fastdebug make test TEST=java/net/spi/InetAddressResolverProvider/RuntimePermissionTest.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1"

STDOUT:
test RuntimePermissionTest.noRuntimePermission(): failure
java.lang.StackOverflowError
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.callStackWalk(Native Method)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.beginStackWalk(StackStreamFactory.java:410)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.walkHelper(StackStreamFactory.java:261)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.walk(StackStreamFactory.java:253)
        at java.base/java.lang.StackWalker.walk(StackWalker.java:589)
        at java.logging/java.util.logging.LogRecord$CallerFinder.get(LogRecord.java:784)
        at java.logging/java.util.logging.LogRecord.inferCaller(LogRecord.java:757)
        at java.logging/java.util.logging.LogRecord.getSourceClassName(LogRecord.java:351)
        at java.logging/java.util.logging.SimpleFormatter.format(SimpleFormatter.java:163)
        at java.logging/java.util.logging.StreamHandler.publish0(StreamHandler.java:241)
        at java.logging/java.util.logging.StreamHandler.publish(StreamHandler.java:224)
        at java.logging/java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:95)
        at java.logging/java.util.logging.Logger.log(Logger.java:983)
        at java.logging/java.util.logging.Logger.doLog(Logger.java:1010)
        at java.logging/java.util.logging.Logger.log(Logger.java:1033)
        at java.logging/java.util.logging.Logger.info(Logger.java:1806)
        at RuntimePermissionTest$TestSecurityManager.checkPermission(RuntimePermissionTest.java:88)
        at java.base/java.lang.Module.getClassLoader(Module.java:218)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
        at java.base/java.lang.Class.forName(Class.java:622)
        at java.base/java.lang.Class.forName(Class.java:603)
        at java.base/sun.util.resources.Bundles.findBundleOf(Bundles.java:205)
        at java.base/sun.util.resources.Bundles.findBundleOf(Bundles.java:160)
        at java.base/sun.util.resources.Bundles.findBundleOf(Bundles.java:160)

I now believe this is a duplicate of JDK-8316113.
12-09-2023
In current mainline, this is highly intermittent, about 1/100 runs fail. I see that some work had already been done around similar SOEs, JDK-8314263. I suspect that Shenandoah configs were just "lucky" to hit a similar SOE. This part of the stack repeats now: ``` at RuntimePermissionTest$TestSecurityManager.checkPermission(RuntimePermissionTest.java:88) at java.base/java.lang.Module.getClassLoader(Module.java:218) at java.base/java.security.AccessController.doPrivileged(AccessController.java:319) at java.base/java.lang.Class.forName(Class.java:622) at java.base/java.lang.Class.forName(Class.java:603) at java.base/sun.util.resources.Bundles.findBundleOf(Bundles.java:205) at java.base/sun.util.resources.Bundles.findBundleOf(Bundles.java:160) at java.base/sun.util.resources.Bundles.findBundleOf(Bundles.java:160) at java.base/sun.util.resources.Bundles.loadBundleOf(Bundles.java:145) at java.base/sun.util.resources.Bundles.of(Bundles.java:106) at java.base/sun.util.resources.LocaleData$1.run(LocaleData.java:185) at java.base/sun.util.resources.LocaleData$1.run(LocaleData.java:182) at java.base/java.security.AccessController.doPrivileged(AccessController.java:319) at java.base/sun.util.resources.LocaleData.getBundle(LocaleData.java:182) at java.base/sun.util.resources.LocaleData.getDateFormatData(LocaleData.java:145) at java.base/java.text.DateFormatSymbols.initializeData(DateFormatSymbols.java:745) at java.base/java.text.DateFormatSymbols.<init>(DateFormatSymbols.java:151) at java.base/sun.util.locale.provider.DateFormatSymbolsProviderImpl.getInstance(DateFormatSymbolsProviderImpl.java:85) at java.base/java.text.DateFormatSymbols.getProviderInstance(DateFormatSymbols.java:371) at java.base/java.text.DateFormatSymbols.getInstance(DateFormatSymbols.java:347) at java.base/java.util.Formatter$FormatSpecifier.print(Formatter.java:4411) at java.base/java.util.Formatter$FormatSpecifier.print(Formatter.java:4282) at java.base/java.util.Formatter$FormatSpecifier.printDateTime(Formatter.java:3105) at java.base/java.util.Formatter$FormatSpecifier.print(Formatter.java:3014) at java.base/java.util.Formatter.format(Formatter.java:2797) at java.base/java.util.Formatter.format(Formatter.java:2728) at java.base/java.lang.String.format(String.java:4386) at java.logging/java.util.logging.SimpleFormatter.format(SimpleFormatter.java:181) at java.logging/java.util.logging.StreamHandler.publish0(StreamHandler.java:241) at java.logging/java.util.logging.StreamHandler.publish(StreamHandler.java:224) at java.logging/java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:95) at java.logging/java.util.logging.Logger.log(Logger.java:983) at java.logging/java.util.logging.Logger.doLog(Logger.java:1010) at java.logging/java.util.logging.Logger.log(Logger.java:1033) at java.logging/java.util.logging.Logger.info(Logger.java:1806) at RuntimePermissionTest$TestSecurityManager.checkPermission(RuntimePermissionTest.java:88) ```
12-09-2023
Seems to reproduce on Linux x86_64, but not on MacOS AArch64.
04-09-2023
More clues. This passes: % CONF=linux-x86_64-server-fastdebug make test TEST=java/net/spi/InetAddressResolverProvider/RuntimePermissionTest.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1 -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCMode=passive" JTREG=REPEAT_COUNT=10 This does not: % CONF=linux-x86_64-server-fastdebug make test TEST=java/net/spi/InetAddressResolverProvider/RuntimePermissionTest.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1 -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCMode=passive -XX:+ShenandoahLoadRefBarrier -XX:+ShenandoahSATBBarrier" JTREG=REPEAT_COUNT=10 This suggests a bug somewhere in Shenandoah LRB or SATB C1 barriers.
04-09-2023
Bisected to JDK-8304745, hm. Reverting JDK-8304745 makes the test pass!
04-09-2023

Duplicate :	JDK-8316113 - Infinite permission checking loop in java/net/spi/InetAddressResolverProvider/RuntimePermissionTest
Relates :	JDK-8316113 - Infinite permission checking loop in java/net/spi/InetAddressResolverProvider/RuntimePermissionTest