... mindkettő beledöglik a 2.2250738585072011e-308 számba.
(-1) küldte a hírt, hogy a január elején itt is szóba került PHP problémához kísértetiesen hasonlót fedeztek fel a legújabb java futtatókörnyezetben és a fordítóban is!
Az ExploringBinary cikke a következő két egyszerű forráskódot tette közzé a hiba demonstrálására, az első osztály a JRE-t, a másik a javac-t fekteti meg:
class runhang {
public static void main(String[] args) {
System.out.println("Test:");
double d = Double.parseDouble("2.2250738585072012e-308");
System.out.println("Value: " + d);
}
}
class compilehang {
public static void main(String[] args) {
double d = 2.2250738585072012e-308;
System.out.println("Value: " + d);
}
}
Ráadásként a tizedesjel odéppakolásával és nullák beillesztésével további számok konstruálhatók, melyek mindegyike végtelen ciklusba kergeti az interpretert/fordítót.
2011.02.01. 19:18:40
2011.02.01. 19:20:13
2011.02.01. 19:20:53
maaaargit · http://katasztrofail.blog.hu/ 2011.02.01. 20:14:54
ruby-1.8.7-p330 :001 > n =2.2250738585072011e-308
=> 2.2250738585072e-308
ruby-1.8.7-p330 :002 > n
=> 2.2250738585072e-308
ruby-1.8.7-p330 :003 > n/2
=> 1.1125369292536e-308
EQ · http://rycon.hu 2011.02.01. 21:43:59
nyos 2011.02.02. 04:09:06
Mert a PHP-bol is csak a 32-eset erintette.
Javaval mi a helyzet? Ott mindegyik erintett?
nyos 2011.02.02. 04:10:30
Mert a PHP-bol is csak a 32-eset erintette.
Javaval mi a helyzet? Ott mindegyik erintett?
(elobb valami blog.hu bug volt, bocs, ha dupla)
whocares11 2011.02.02. 06:36:18
axt · http://axtaxt.wordpress.com/ 2011.02.02. 07:40:32
deejayy · http://deejayy.hu/ 2011.02.02. 07:57:15
axt · http://axtaxt.wordpress.com/ 2011.02.02. 08:20:47
loolek · http://loolek.tumblr.com 2011.02.02. 09:11:35
D:\>javac -verbose compilehang.java
[parsing started compilehang.java] A
[parsing completed 15ms]
[search path for source files: .]
[search path for class files: c:\jdk1.6.0_23\jre\lib\resources.jar,c:\jdk1.6.0_23\jre\lib\rt.jar,c:\jdk1.6.0_23\jre\lib\sunrsasign.jar,c:\jdk1.6.0_23\j
re\lib\jsse.jar,c:\jdk1.6.0_23\jre\lib\jce.jar,c:\jdk1.6.0_23\jre\lib\charsets.jar,c:\jdk1.6.0_23\jre\lib\modules\jdk.boot.jar,c:\jdk1.6.0_23\jre\class
es,c:\jdk1.6.0_23\jre\lib\ext\dnsns.jar,c:\jdk1.6.0_23\jre\lib\ext\localedata.jar,c:\jdk1.6.0_23\jre\lib\ext\sunjce_provider.jar,c:\jdk1.6.0_23\jre\lib
\ext\sunmscapi.jar,c:\jdk1.6.0_23\jre\lib\ext\sunpkcs11.jar,.]
[loading java\lang\Object.class(java\lang:Object.class)]
[loading java\lang\String.class(java\lang:String.class)]
[checking compilehang]
[loading java\lang\System.class(java\lang:System.class)]
[loading java\io\PrintStream.class(java\io:PrintStream.class)]
[loading java\io\FilterOutputStream.class(java\io:FilterOutputStream.class)]
[loading java\io\OutputStream.class(java\io:OutputStream.class)]
[loading java\lang\StringBuilder.class(java\lang:StringBuilder.class)]
[loading java\lang\AbstractStringBuilder.class(java\lang:AbstractStringBuilder.class)]
[loading java\lang\CharSequence.class(java\lang:CharSequence.class)]
[loading java\io\Serializable.class(java\io:Serializable.class)]
[loading java\lang\Comparable.class(java\lang:Comparable.class)]
[loading java\lang\StringBuffer.class(java\lang:StringBuffer.class)]
[wrote compilehang.class]
[total 156ms]
Viszont, ha a megadott érték, akkor egyből kifagy a parser:
D:\>javac -verbose compilehang.java
[parsing started compilehang.java]
Tyra3l 2011.02.02. 11:02:54
buherablog-tol tobbet vartam.
Tyrael
Tyra3l 2011.02.02. 11:13:40
gcc.gnu.org/bugzilla/show_bug.cgi?id=323
anno a python is belefutott
bugs.python.org/issue2937
nemreg a php, most a java (clojure, scala, etc.)
valoszinuleg ha jol korulneznenk, akkor vagy mas projectek is szivtak vele (2000-es az eredeti gcc-s hibajegy), vagy meg mindig tartalmazzak a hibat.
remelhetoleg a 64bit terjedesevel vegleg elfelejtkezhetunk errol a problemarol.
Tyrael
buherator · http://buhera.blog.hu 2011.02.02. 11:23:06
Egyébként axtaxt kommentje szerint 64 bites Java-n is tapasztalható a jelenség.
Tyra3l 2011.02.02. 12:04:33
illetve a javas eset kapcsan a legerdekesebb commentek szerintem itt szulettek az altalad linkelt poston kivul:
hackerne.ws/item?id=2164863
pl. JRuby is erintett, ha hinni lehet az egyik commentelonek (ami logikus lenne, hiszen mint irtam, maga a JVM szenved a problematol)
Tyrael
loolek · http://loolek.tumblr.com 2011.02.02. 17:26:01
The x87 FPU was originally designed in (or before) 1980. I think that's why it
is quite simple: it has only one unit for all FP data types. Of course, the
precision must be of the widest type, which is the 80-bit long double.
Consider you have a program, where all the FP variables are of the type double.
You perform some FP operations and one of them is e.g. 1e-300/1e300, which
results in 1e-600. Despite this value cannot be held by a "double", it is
stored in an 80-bit FPU register as the result. Consider you use the variable
"x" to hold that result. If the program has been compiled with optimization,
the value need not be stored in RAM. So, say, it is still in the register.
Consider you need x to be nonzero, so you perform the test x != 0. Since 1e-600
is not zero, the test yields true. While you perform some other computations,
the value is moved to RAM and converted to 0 because x is of type "double". Now
you want to use your certainly nonzero x... Hard luck :-(
Note that if the result doesn't have its corresponding variable and you perform
the test directly on an expression, the problem can come to light even without
optimization.
It could seem that performing all FP operations in extended precision can bring
benefits only. But it introduces a serious pitfall: moving a value may change
the value!!!
more: hal.archives-ouvertes.fr/hal-00128124