RFR: regex changes -- sun.security.util.Debug issue
Sean Mullan
sean.mullan at oracle.com
Wed May 11 00:36:44 UTC 2016
Hi Xueming,
It looks ok to me, but I'm curious if there may be other security
classes that are initialized quite early and write to debug and may run
into similar issues. Did you run all of the security regression tests in
the jprt job?
--Sean
On 5/10/16 11:57 AM, Xueming Shen wrote:
> webrev has been updated as suggested, now the lazily-init-class-holder
> is used
> to delay the Debug initialization. Tests all passed locally. A jprt job
> is out to confirm.
>
> Here is the updated webrev
>
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/
>
> Thanks!
> Sherman
>
> On 05/10/2016 01:30 AM, Alan Bateman wrote:
>> On 10/05/2016 06:36, Xueming Shen wrote:
>>> 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.
>> This is always tricky but I wonder how far we could get by
>> initializing ProtectionDomain.debug and SecureClassLoader.debug
>> lazily. That is, move them to a holder class where I wouldn't expect
>> they will be initialized until much later, esp. as the security
>> manager won't be set until later in the initialization (or init phase
>> 3 as we've come to name it).
>>
>> -Alan
>
>
>
More information about the security-dev
mailing list