[testbug] RFR: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference
Lance Andersen
lance.andersen at oracle.com
Thu Jan 24 12:39:36 UTC 2019
Looking good still Daniel :-)
> On Jan 24, 2019, at 7:20 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>
> Thanks Lance.
>
> Meanwhile I noticed that the first loop calling gc() used
> a sleep(100) - which is probably not enough in those
> greedy configurations - so I extended that to 1000.
> (webrev updated in place).
> http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/
>
> Hopefully that will reduce the frequency of failures.
> Re testing in progress...
>
> best regards,
>
> -- daniel
>
> On 24/01/2019 12:14, Lance Andersen wrote:
>> Morning Daniel,
>> The change seems like a good approach
>> Best
>> Lance
>>> On Jan 24, 2019, at 6:42 AM, Daniel Fuchs <daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>> wrote:
>>>
>>> Hi,
>>>
>>> Please find below a fix for:
>>>
>>> 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java
>>> fails with Unexpected reference: java.lang.ref.WeakReference
>>> https://bugs.openjdk.java.net/browse/JDK-8217353
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/
>>>
>>> This test has been seen failing from time to time with an
>>> exception originating from the finally { } clause of the
>>> main method. The suspicion is that this exception in fact
>>> hides another exception previously thrown in the try { }
>>> body.
>>>
>>> This is only a fix in so far that it will ensure that the
>>> real exception - if any - is added to the suppressed list
>>> of the secondary exception so that we eventually see it in
>>> the log.
>>>
>>> As to why the test failed in the first place - I am not quite
>>> sure, but it might be due to -Xcomp or some other combination
>>> of options preventing the WeakReference to be cleared within
>>> the time (and number of gc() calls) expected by the test
>>> (the test has never been seen failing without these combinations).
>>>
>>> best regards,
>>>
>>> -- daniel
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
More information about the core-libs-dev
mailing list