[jira] Closed: (HARMONY-3619) Object.wait(Long.MAX_VALUE) exits immediately

["Sergey Dmitriev (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HARMONY-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Dmitriev closed HARMONY-3619.
------------------------------------


> Object.wait(Long.MAX_VALUE) exits immediately
> ---------------------------------------------
>
>                 Key: HARMONY-3619
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3619
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Linux
>            Reporter: Sergey Dmitriev
>         Assigned To: Gregory Shimansky
>         Attachments: 3619.patch, 3619_test.patch
>
>
> Current implementation of Object.wait(long ms[, long nano]) behaves
> incorrectly in case of big enough 'ms', for example equal to
> Long.MAX_VALUE. Meaning that in such cases Object.wait() just returns
> immediately. (See below to find out what 'big enough' means here). We
> are talking about linux.
> Here is the mini test:
> --- currenttimemillis.java ---
> public class currenttimemillis {
>     public static void main(String args[]) throws Exception {
>         String lock = "lock";
>         synchronized (lock) {
>             lock.wait(Long.MAX_VALUE, 0);
>         }
>         System.out.println("Actually you should see this message after approx " +
>                            Long.MAX_VALUE/1000/60/24/365 + " years.");
>  
>     }
> }
> --- console logs ---
> ] sam@linuxbox
> ] java -showversion currenttimemillis
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
> BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-linux-ia32, R25.0.0-75, GC: System optimized over throughput (initial strategy singleparpar))
>  
> // hangs up as expected
> ^C
> ] sam@linuxbox
> ] ~/jre.0804-gcc-debug/bin/java -showversion currenttimemillis                                                            
> Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable.
> java version "1.5.0" 
> pre-alpha : not complete or compatible
> svn = r526433, (Apr  8 2007), Linux/ia32/gcc 3.3.3, debug build
> http://incubator.apache.org/harmony
> Actually you should see this message after approx 17548272520 years.
> The root problem goes from the vm/thread/src/linux/os_condvar.c,
> method os_cond_timewait(hycond *cond, hymutex_t *mutex, I_64 ms, IDATA nano).
> This method incorrectly converts the provided wait period from the
> ms:nanos format into the sec:nanos format (absolute time from the
> epoch) which is acceptable by pthreads. The first mistake here is the
> multiplication of 'ms' (64 bit value) by 1000 at:
>        apr_time_t then = apr_time_now() + ms*1000 + nano/1000;
> If we have a 'big enough' 'ms' value - overflow comes into play.
> So I've attached the proposed fix for the code (regression test patch
> on its way). One note: the code fix assumes that the 'nano' parameter
> can be more than 999999 to not to risk. Since it is unclear whether
> the 'nano' is 100% lays in [0-999999] segment. (See
> java.lang.Object#wait(long, long) javadoc). If someone can advocate
> that 'nano' is always in [0-999999] or provide appropriate comments
> here we can remove a couple of divisions/modulos from the patch.
> This issue is not repro on Win32.
> Thanks to Aleksey Shipilev and Rustem Rafikov for helping me in
> tracing this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.