-
Bug
-
Resolution: Fixed
-
P4
-
6u21
-
b10
-
x86
-
linux
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2215814 | 7u80 | Sean Coffey | P4 | Resolved | Fixed | b02 |
JDK-8061050 | 7u79 | Sean Coffey | P4 | Resolved | Fixed | b01 |
JDK-8057374 | 7u76 | Sean Coffey | P4 | Resolved | Fixed | b01 |
JDK-2215813 | 6u30 | Sean Coffey | P4 | Closed | Fixed | b10 |
FULL PRODUCT VERSION :
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
Note: this also occurs in 6u21 but it is not the version we are recommending at this point.
ADDITIONAL OS VERSION INFORMATION :
Linux <hostname obscured> 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
When a java.util.Date is converted to a String the TimeZone is needed. During the retrieval of the timezone information the native method repeatedly tries to close the file descriptor number -1 which causes an error with EBADF.
We are running with the JRE embedded and sandboxed within a database server with full control of all system calls (such as close()).
Looking at the source for findZoneinfoFile() in TimeZone_md.c we see the fd initialized to -1 at the top of the method. Further down we recursively mill through the directory entries at each level in the big while loop. When we finish with a level we cleanup, including a file close:
if (fd != 0) {
(void) close(fd);
}
Note that the close checks for fd != 0 so we incorrectly attempt to close a bad file descriptor (for timezones we are not using no file is opened). The fd should either be initialized to 0 or the close check should exclude -1 as well.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Outside of the Sybase ASE server the equivalent java call is simply:
public static void doit()
{
java.util.Date d = new java.util.Date()
System.out.println( d );
}
We go into the native method TimeZone.getSystemTimeZoneID at this point
main[1] where
[1] java.util.TimeZone.setDefaultZone (TimeZone.java:559)
[2] java.util.TimeZone.getDefaultRef (TimeZone.java:550)
[3] java.util.Date.normalize (Date.java:1,193)
[4] java.util.Date.toString (Date.java:1,027)
[5] java.lang.String.valueOf (String.java:2,838)
[6] java.io.PrintStream.println (PrintStream.java:788)
[7] Foo.doit (Foo.java:4)
[8] Foo.main (Foo.java:9)
Everything is happening under the covers when doing the timezone lookup
(gdb) where
#0 0x0000000001c8d406 in pci_coma (timeout=0) at /marslinux3_imet_eng/asebharani_wtenhave_vu/calm/svr/sql/generic/pci/bridge/bridge.c:1553
#1 0x00002aaaaee2c25a in pca_close (func=0x316be0d950 <close>, fd=-1) at /marslinux3_imet_eng/asebharani_wtenhave_vu/calm/svr/sql/generic/pci/plugins/jvm/hostapi.c:972
#2 0x0000000001cdeb5c in close (fd=-1) at /marslinux3_imet_eng/asebharani_wtenhave_vu/calm/svr/sql/generic/pci/bridge/pciruntime.c:1808
#3 0x00002aaab02e9ebd in findZoneinfoFile () from /marslinux3_imet_eng/asebharani_wtenhave_vu/sybase.64.SMP/shared/JRE-6_0_20_64BIT/lib/amd64/libjava.so
#4 0x00002aaab02e9ed9 in findZoneinfoFile () from /marslinux3_imet_eng/asebharani_wtenhave_vu/sybase.64.SMP/shared/JRE-6_0_20_64BIT/lib/amd64/libjava.so
#5 0x00002aaab02ea1ba in getPlatformTimeZoneID () from /marslinux3_imet_eng/asebharani_wtenhave_vu/sybase.64.SMP/shared/JRE-6_0_20_64BIT/lib/amd64/libjava.so
#6 0x00002aaab02e9f77 in findJavaTZ_md () from /marslinux3_imet_eng/asebharani_wtenhave_vu/sybase.64.SMP/shared/JRE-6_0_20_64BIT/lib/amd64/libjava.so
#7 0x00002aaab02e9b69 in Java_java_util_TimeZone_getSystemTimeZoneID () from /marslinux3_imet_eng/asebharani_wtenhave_vu/sybase.64.SMP/shared/JRE-6_0_20_64BIT/lib/amd64/libjava.so
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
close(fd) should return 0 (success)
ACTUAL -
close(fd) returns -1 with EBADF for a reason
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public class Foo
public static void doit() {
java.util.Date d = new java.util.Date();
System.out.println(d);
}
public static void main(String[] a)
{
doit();
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Most users will not see this. We have worked around internally but at the cost of masking other potential errors with incorrect file i/o.
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
Note: this also occurs in 6u21 but it is not the version we are recommending at this point.
ADDITIONAL OS VERSION INFORMATION :
Linux <hostname obscured> 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
When a java.util.Date is converted to a String the TimeZone is needed. During the retrieval of the timezone information the native method repeatedly tries to close the file descriptor number -1 which causes an error with EBADF.
We are running with the JRE embedded and sandboxed within a database server with full control of all system calls (such as close()).
Looking at the source for findZoneinfoFile() in TimeZone_md.c we see the fd initialized to -1 at the top of the method. Further down we recursively mill through the directory entries at each level in the big while loop. When we finish with a level we cleanup, including a file close:
if (fd != 0) {
(void) close(fd);
}
Note that the close checks for fd != 0 so we incorrectly attempt to close a bad file descriptor (for timezones we are not using no file is opened). The fd should either be initialized to 0 or the close check should exclude -1 as well.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Outside of the Sybase ASE server the equivalent java call is simply:
public static void doit()
{
java.util.Date d = new java.util.Date()
System.out.println( d );
}
We go into the native method TimeZone.getSystemTimeZoneID at this point
main[1] where
[1] java.util.TimeZone.setDefaultZone (TimeZone.java:559)
[2] java.util.TimeZone.getDefaultRef (TimeZone.java:550)
[3] java.util.Date.normalize (Date.java:1,193)
[4] java.util.Date.toString (Date.java:1,027)
[5] java.lang.String.valueOf (String.java:2,838)
[6] java.io.PrintStream.println (PrintStream.java:788)
[7] Foo.doit (Foo.java:4)
[8] Foo.main (Foo.java:9)
Everything is happening under the covers when doing the timezone lookup
(gdb) where
#0 0x0000000001c8d406 in pci_coma (timeout=0) at /marslinux3_imet_eng/asebharani_wtenhave_vu/calm/svr/sql/generic/pci/bridge/bridge.c:1553
#1 0x00002aaaaee2c25a in pca_close (func=0x316be0d950 <close>, fd=-1) at /marslinux3_imet_eng/asebharani_wtenhave_vu/calm/svr/sql/generic/pci/plugins/jvm/hostapi.c:972
#2 0x0000000001cdeb5c in close (fd=-1) at /marslinux3_imet_eng/asebharani_wtenhave_vu/calm/svr/sql/generic/pci/bridge/pciruntime.c:1808
#3 0x00002aaab02e9ebd in findZoneinfoFile () from /marslinux3_imet_eng/asebharani_wtenhave_vu/sybase.64.SMP/shared/JRE-6_0_20_64BIT/lib/amd64/libjava.so
#4 0x00002aaab02e9ed9 in findZoneinfoFile () from /marslinux3_imet_eng/asebharani_wtenhave_vu/sybase.64.SMP/shared/JRE-6_0_20_64BIT/lib/amd64/libjava.so
#5 0x00002aaab02ea1ba in getPlatformTimeZoneID () from /marslinux3_imet_eng/asebharani_wtenhave_vu/sybase.64.SMP/shared/JRE-6_0_20_64BIT/lib/amd64/libjava.so
#6 0x00002aaab02e9f77 in findJavaTZ_md () from /marslinux3_imet_eng/asebharani_wtenhave_vu/sybase.64.SMP/shared/JRE-6_0_20_64BIT/lib/amd64/libjava.so
#7 0x00002aaab02e9b69 in Java_java_util_TimeZone_getSystemTimeZoneID () from /marslinux3_imet_eng/asebharani_wtenhave_vu/sybase.64.SMP/shared/JRE-6_0_20_64BIT/lib/amd64/libjava.so
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
close(fd) should return 0 (success)
ACTUAL -
close(fd) returns -1 with EBADF for a reason
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public class Foo
public static void doit() {
java.util.Date d = new java.util.Date();
System.out.println(d);
}
public static void main(String[] a)
{
doit();
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Most users will not see this. We have worked around internally but at the cost of masking other potential errors with incorrect file i/o.
- backported by
-
JDK-2215814 Invalid close of file descriptor '-1' in findZoneinfoFile
-
- Resolved
-
-
JDK-8057374 Invalid close of file descriptor '-1' in findZoneinfoFile
-
- Resolved
-
-
JDK-8061050 Invalid close of file descriptor '-1' in findZoneinfoFile
-
- Resolved
-
-
JDK-2215813 Invalid close of file descriptor '-1' in findZoneinfoFile
-
- Closed
-