[Статья] Фризим сервер в пару копий

[RazvalSaraev]

Недавно зашел на блог "ПХешечки" незнаю может кто видел может нет , но есть такой способ "Зафризить и положить сервер за пару минут " пару раз поюзал данную дырочку на разных ОБТ и вообщем на 60% серверов это работает. Ну вообщем дело в том что при копирование данного кода ==2.2250738585072012e-308 БЕЗ ПРОБЕЛОВ! Начинается бешеная загрузка ЦП , после 5 подряд написанных раза , сервер начнет лагать вы заметите


Если тема является "копипастом прошу прощения" но данной темы нету вроде бы

[letitbe]

Да, действительно, Java зависает на 2.2250738585072012e-308
Java — и рантайм и компилятор — входит в бесконечный цикл при конвертации десятичного 2.2250738585072012e-308 в double. По идее, число должно быть преобразовано в 0x1p-1022, то есть Double.MIN_VALUE. Однако, Java зависает на 0x0.fffffffffffffp-1022, самом большом [Ссылки могут видеть только зарегистрированные пользователи. ] для double.
Бесконечный цикл в runtime

PHP код:

class RuntimeHang {
    public static void main(String[] args) {
        System.out.println("Test:");
        double d = Double.parseDouble("2.2250738585072012e-308");
        System.out.println("Value: " + d);
    }
} 


Бесконечный цикл во время компиляции
(Если вы хотите опробовать это в Eclipse, не забудьте сначала всё сохранить, а то с его теневой компиляцией и опомниться не успеете — прим. перев.)

PHP код:

class CompilationHang {
    public static void main(String[] args) {
        double d = 2.2250738585072012e-308;
        System.out.println("Value: " + d);
    }
} 


Под катом рассуждения автора насчёт причин этого явления.
В чём же дело?
Константин Прайссер (Konstantin Preisser) выяснил, что по крайней мере в рантайме проблема кроется в «цикле коррекции» в [Ссылки могут видеть только зарегистрированные пользователи. ]. Он пишет:

Если закомментировать эту часть, в рантайме зависания больше нет, поскольку Double.parseDouble(String s), который вызывает sun.misc.FloatingDecimal.readJavaFormatString(s).doubleValue() — код на чистой java, ничего нативного. Но там используется артифметика чисел с плавающей точкой, так что дело может быть в настройках компилятора, в котором компилировали JRE и javac.

 Без цикла коррекции выходят такие биты (big endian):
00000000 00001111 11111111 11111111 11111111 11111111 11111111 11111111

 То есть, число конвертируется в самое большое денормализованное число с плавающей точкой, поскольку экспонента нулевая. Без цикла коррекции то же самое происходит и с 2.2250738585072013e-308, однако если цикл раскомментировать, то сконвертируется правильно:
00000000 00010000 00000000 00000000 00000000 00000000 00000000 00000000