RFR: regex changes -- sun.security.util.Debug issue

Xueming Shen xueming.shen at oracle.com
Tue May 10 05:36:29 UTC 2016


Hi,

While testing for the attached regex changes, a fatal vm init error was 
triggered for test
case with -Djava.security.debug=xyz turned on, as showed in following 
stacktrace.

It appears sun.security.util.Debug is being initialized even before the 
lambda is ready
for use, and unfortunately it uses j.u.regex (for its args parsing), 
which is being migrated
to use lambda function in the proposed regex change.

Since Debug is the only class now triggers j.u.regex -> lambda during 
initialization, it
is suggested to update/rewrite the related method in Debug to NOT use 
j.u.regex to
solve/workaround this specific initialization issue.

The webrev below has been updated to include such a change.

http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/

The sun.security.util.Debug related change is at

http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/src/java.base/share/classes/sun/security/util/Debug.java.sdiff.html

Can security-dev guys help take a look if this is an 
acceptable/reasonable approach.

Thanks,
Sherman

-----------------------------------------------------------------------------

Caused by: java.lang.ExceptionInInitializerError


	at jdk.internal.loader.BootLoader.loadClassOrNull(java.base/BootLoader.java:110)
	at java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:497)
	at java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:492)
...
	at java.lang.invoke.MethodHandleNatives.linkCallSite(java.base/MethodHandleNatives.java:240)
	at java.util.regex.Pattern.<clinit>(java.base/Pattern.java:5682)
	at sun.security.util.Debug.marshal(java.base/Debug.java:247)
	at sun.security.util.Debug.<clinit>(java.base/Debug.java:59)
	at java.security.ProtectionDomain.<clinit>(java.base/ProtectionDomain.java:142)
	at jdk.internal.misc.InnocuousThread.<clinit>(java.base/InnocuousThread.java:129)
	at jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:48)
	at jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:45)
	at java.security.AccessController.doPrivileged(java.base/Native Method)
	at jdk.internal.ref.CleanerFactory$1.newThread(java.base/CleanerFactory.java:45)
	at jdk.internal.ref.CleanerImpl.start(java.base/CleanerImpl.java:116)
	at java.lang.ref.Cleaner.create(java.base/Cleaner.java:203)
	at jdk.internal.ref.CleanerFactory.<clinit>(java.base/CleanerFactory.java:42)
	at sun.nio.fs.NativeBuffer.<init>(java.base/NativeBuffer.java:60)
	at sun.nio.fs.NativeBuffers.allocNativeBuffer(java.base/NativeBuffers.java:49)
	at sun.nio.fs.UnixNativeDispatcher.copyToNativeBuffer(java.base/UnixNativeDispatcher.java:44)
	at sun.nio.fs.UnixNativeDispatcher.stat(java.base/UnixNativeDispatcher.java:306)
	at sun.nio.fs.UnixFileSystemProvider.isRegularFile(java.base/UnixFileSystemProvider.java:514)
	at java.nio.file.Files.isRegularFile(java.base/Files.java:2244)
	at java.lang.module.ModuleFinder.ofSystem(java.base/ModuleFinder.java:165)
	at jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:105)
	at java.lang.System.initPhase2(java.base/System.java:1924)

---------------------------------------------------------------------------------


On 3/18/16 1:05 PM, Xueming Shen wrote:
> Hi,
>
> There are couple regex related changes waiting for review. I have pull 
> them
> together here (with the notes) to make it easy to review.
>
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/
>
> (1) Exponential backtracking
>
> Note: 
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/backtracking
>
> https://bugs.openjdk.java.net/browse/JDK-6328855
> https://bugs.openjdk.java.net/browse/JDK-6192895
> https://bugs.openjdk.java.net/browse/JDK-6345469
> https://bugs.openjdk.java.net/browse/JDK-6988218
> https://bugs.openjdk.java.net/browse/JDK-6693451
> https://bugs.openjdk.java.net/browse/JDK-7006761
> https://bugs.openjdk.java.net/browse/JDK-8140212
>
> (2) Anonymous class to lambda function cleanup
>
> Note: 
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction
>
> https://bugs.openjdk.java.net/browse/JDK-8151481
> https://bugs.openjdk.java.net/browse/JDK-6609854
>
> (3) Canonical Equivalents
>
> Note: 
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/canonEQ
>
> https://bugs.openjdk.java.net/browse/JDK-4916384
> https://bugs.openjdk.java.net/browse/JDK-4867170
> https://bugs.openjdk.java.net/browse/JDK-6995635
> https://bugs.openjdk.java.net/browse/JDK-6728861
> https://bugs.openjdk.java.net/browse/JDK-6736245
> https://bugs.openjdk.java.net/browse/JDK-7080302
>
> Thanks
> Sherman


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20160509/114a1e9f/attachment.htm>


More information about the security-dev mailing list