harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Dmitriev (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-3619) Object.wait(Long.MAX_VALUE) exits immediately
Date Wed, 11 Apr 2007 08:55:32 GMT
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

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

] 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
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.

View raw message