[testbug] RFR: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference

Daniel Fuchs daniel.fuchs at oracle.com
Thu Jan 24 16:35:36 UTC 2019


Thanks Igor,

On 24/01/2019 15:59, Igor Ignatyev wrote:
> Hi Daniel,
> 
> it might be a better idea to scale sleep time using jdk.test.lib.Utils::adjustTimeout, so it will remain the same on configuration w/ timeout-factor=1, and scaled proportionally to timeout-factor on slow configurations. the rest looks good.

I've chosen a slightly different path and adjusted the number of
iterations instead:
http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.01

best regards,

-- daniel

> 
> Thanks,
> -- Igor
> 
>> On Jan 24, 2019, at 4: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>
>>
> 



More information about the core-libs-dev mailing list