You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Sergey Dmitriev (JIRA)" <ji...@apache.org> on 2007/04/11 10:55:32 UTC
[jira] Created: (HARMONY-3619) Object.wait(Long.MAX_VALUE) exits
immediately
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
^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.
[jira] Closed: (HARMONY-3619) Object.wait(Long.MAX_VALUE) exits
immediately
Posted by "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.
[jira] Commented: (HARMONY-3619) Object.wait(Long.MAX_VALUE) exits
immediately
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488854 ]
Sergey Dmitriev commented on HARMONY-3619:
------------------------------------------
Patch injected just fine. Thanks!
> 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.
[jira] Resolved: (HARMONY-3619) Object.wait(Long.MAX_VALUE) exits
immediately
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky resolved HARMONY-3619.
----------------------------------------
Resolution: Fixed
Patch applied at 528473. Please check that the bug is fixed now.
> 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.
[jira] Updated: (HARMONY-3619) Object.wait(Long.MAX_VALUE) exits
immediately
Posted by "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 updated HARMONY-3619:
-------------------------------------
Attachment: 3619_test.patch
Second (correct) version of tests patch.
> 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
> 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.
[jira] Assigned: (HARMONY-3619) Object.wait(Long.MAX_VALUE) exits
immediately
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky reassigned HARMONY-3619:
------------------------------------------
Assignee: Gregory Shimansky
> 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.
[jira] Updated: (HARMONY-3619) Object.wait(Long.MAX_VALUE) exits
immediately
Posted by "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 updated HARMONY-3619:
-------------------------------------
Attachment: (was: 3619_test.patch)
> 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
> 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.
[jira] Updated: (HARMONY-3619) Object.wait(Long.MAX_VALUE) exits
immediately
Posted by "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 updated HARMONY-3619:
-------------------------------------
Attachment: 3619.patch
> 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
> Attachments: 3619.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.
[jira] Updated: (HARMONY-3619) Object.wait(Long.MAX_VALUE) exits
immediately
Posted by "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 updated HARMONY-3619:
-------------------------------------
Attachment: 3619_test.patch
> 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
> 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.