Java Floating Point Bug Can Lock Up Servers
An anonymous reader writes "Here we go again: Just like the recently-reported PHP Floating Point Bug causes servers to go into infinite loops when parsing certain double-precision floating-point numbers, Sun/Oracle's JVM does it, too. It gets better: you can lock up a thread on most servers just by sending a particular header value. Sun/Oracle has known about the bug for something like 10 years, but it's still not fixed. Java Servlet containers are patching to avoid the problem, but application code will still be vulnerable to user input."
Betcha it'll be fixed tomorrow!
Java is a secure virtual machine environment. Programs never crash and low level errors like pointer or memory problems are impossible. There is no way this floating point thing is real.
Java is the future and you are retarded. Java is the fastest programming language ever invented, that's why it's the primary language we learn and teach in school.
I have been a HTML programmer for many years, I know what I'm talking about.
...it's a critical bug in an Adobe product. Then it's going to linger for months, if not years.
There's no -1 for "I don't get it."
dont answer - it wasnt even a day. a shorter fix would only be possible with a time machine.
Read radical news here
Sun/Oracle has known about the bug for something like 10 years.
Those who touted Open Source will not like this piece of news. But they will always find a scapegoat. So much for Open Source!
I've already found the solution to this. Just patch Java to avoid the Pentium FDIV bug! I mean, those Java people are still using Pentiums, right? They claim Java is fast, so it must be the CPUs! Why else would the bug be around for so long?
Be relentless!
But I think I'll stick to running Folding@Home on all cores to burn in thermal paste. Seems more productive, you know?
Orwell: "In a Time of Universal Deceit, telling the Truth is a Revolutionary Act"
Write once, exploit anywhere!
I now uninstall Java from any systems I work on as a security precaution. The auto-update is a nice 'feature', but in most client's systems I work on, none of them have any compelling reason for an installation of Java.
Over two years and no fix for Java
"Sami Koivu has released details of a security vulnerability in Java which he reported to Sun in 2008. A quick test using the current version 1.6.0_23 reveals that it remains unpatched "
As a more than decade-long Java programmer, I must say that I am shocked! Shocked! that Sun would do something like that.
Why, I'd go so far as to predict that a company that behaved that way would find itself out of business.
Hey, wait a second...
Does Java software crash all the time because of this bug? No, of course not, that's one reason Java software is useful at all.
Like with any software, it is essential to prioritize bug fixes. You deal with the bugs that bite you, and save the rest for later.
This is a valid principle for anything made by people, not just software. Somebody might find out, for example, that if you subject a window to a specific frequency of sound, the window will shatter. So what! Don't do that! But...if burglars start going around with a device that emits this frequency, then it's time to come up with an antidote.
Java (like Mac OS) has enjoyed a relatively free ride, when it comes to malicious hackers. It's not that Java is somehow superior, it's just not been an attractive enough target. The fact that it is now being attacked is, in a way, a sign of its success.
Let me clue you in to a little secret: That's not really thermal paste...
You are welcome on my lawn.
The supercomputer Hex. Only at the Unseen University. "Anthill Inside"!
"What in the name of Fats Waller is that?"
"A four-foot prune."
I was working on a gas/billiard ball simulation a couple years ago and kept on running into a bug where the simulation would lock up in an infinite loop, and iirc, that magic number kept popping up. All along I thought it was some sort of bug in my code (it was a horrible hack job; it's almost unmaintainable).
Fuck Beta
DO... NOT... TRY... THIS...
Don't say I haven't warned you!!!!!
Questions raise, answers kill. Raise questions to stay alive.
Well, if it's not thermal gel, thermal compound, thermal paste, heat paste, heat sink paste, heat transfer compound, or heat sink compound, then I don't know what it is. Although if you spend enough time messing with it, I do know it makes a wonderful contraceptive - as G/Fs get tired of being ignored and move on.
Orwell: "In a Time of Universal Deceit, telling the Truth is a Revolutionary Act"
Oracle has posted a fix for the bug, in the form of a patch. Official releases will be available next week. http://www.oracle.com/technetwork/java/javase/fpupdater-tool-readme-305936.html http://blogs.oracle.com/security/2011/02/security_alert_for_cve-2010-44.html
From now on, I'm totally inputting 2.2250738585072011e-308 on every text field that asks for a number.
The code works fine on Android. Guess that they are not running a true JVM.
it's made of people?!
Monstar L
Mod parent up, please
The article makes it clear that the problem is in FloatingDecimal.java. It is converting decimal strings to floating point numbers - fp arithmetic is fine!
How slow is an infinite loop in Java? Now much memory does it take to execute?
make imaginary.friends COUNT=100 VISIBLE=false
Another floating point issue (that hits at a much lower value) ALSO creates infinite loops and has been explained one year ago (without anyone Slashdoting it) while it harms C#, Java or PHP as well as C/C++:
http://gwan.ch/#infiniteloop
Know your tools...
Our GUI mostly does NOT use floating point. When we switched to 1.4, we immediately run into a JVM crash - compiled code improperly handled coprocessor stack.
It is a shame something like this passes testing.
Tomcat is at fault.
The HTTP specs specifies that you should parse at most three digits in the HTTP header "Accepted-language". Tomcat is faulty here for using floating-point to store fixed-precision decimal numbers (hint: Q: how do you store accurately x.yyy in a floating-point number? A: you don't).
So, sure, there's a nasty gigantic Java bug in there. But there's also a case of people using floating-point numbers where they really shouldn't.
2.2250738585072012e-308
should be parsed as "2.225" according to the HTTP specs for the "Accepted-language" HTT header.
It's not just "Java the API" that is a fault here: it's "Java the ecosystem".
Fundamentally, the real issue is about people using floating-point numbers without an epsilon (i.e. for something else than scientific computation). It's like people using floating-point number to store monetary amounts.
It's sad to see such a gross mistake made in Tomcat. This is really noobie 101 stuff.
That is why no Java programmers would ever use "Double.parseDouble"..
In my company they would get fired :-) Even before this bug was known.. It is hard to find a reason for such code anywhere.. Much faster and usable classes out there that would be used in server applications..
Java is a secure virtual machine environment. Programs never crash and low level errors like pointer or memory problems are impossible. There is no way this floating point thing is real.I haven't used floats or doubles in a long time. From a business perspective (think monetary values) it almost always makes more sense to use BigDecimal and apply rounding rules, particularly if those values are stored in a database where scale and precision are known or required. I would imagine the same would be true for scientific values, GIS coordinates, etc. (anything with a known precision). The only use for float/double that comes to mind is something where absolute precision isn't critical and speed is important, such as graphics/physics calculations for games, in which case you generally wouldn't be parsing user-entered values anywatoponlinestudy