No entanto, se você clicar neste link aí em cima, verá que ele não funciona. Quando a Oracle comprou a Sun, vários bugs cadastrados “misteriosamente” sumiram.
Bem, que eu saiba ele não foi consertado até hoje (na época a sun recusou o bug como sendo algo “não importante”). Trata-se do seguinte:
Throwable a = new Throwable();
Throwable b = new Throwable(a);
a.initCause(b);
a.printStackTrace(); // Loop infinito!
Imagina o que acontece se um hacker serializa a exceção para o servidor e o servidor faz o log dela?
No entanto, se você clicar neste link aí em cima, verá que ele não funciona. Quando a Oracle comprou a Sun, vários bugs cadastrados “misteriosamente” sumiram.
Bem, que eu saiba ele não foi consertado até hoje (na época a sun recusou o bug como sendo algo “não importante”). Trata-se do seguinte:
Throwable a = new Throwable();
Throwable b = new Throwable(a);
a.initCause(b);
a.printStackTrace(); // Loop infinito!
Imagina o que acontece se um hacker serializa a exceção para o servidor e o servidor faz o log dela?[/quote]
Se o cadastro sumiu quer dizer que foi corrigido :twisted:
No entanto, se você clicar neste link aí em cima, verá que ele não funciona. Quando a Oracle comprou a Sun, vários bugs cadastrados “misteriosamente” sumiram.
Bem, que eu saiba ele não foi consertado até hoje (na época a sun recusou o bug como sendo algo “não importante”). Trata-se do seguinte:
Throwable a = new Throwable();
Throwable b = new Throwable(a);
a.initCause(b);
a.printStackTrace(); // Loop infinito!
Imagina o que acontece se um hacker serializa a exceção para o servidor e o servidor faz o log dela?[/quote]
Se o cadastro sumiu quer dizer que foi corrigido :twisted: [/quote]
Bem, acabei de testar aqui (Java Hotspot Client VM, versão 1.6.0_22) para ver o que acontecia. Deu um StackOverflowError após ele gerar centenas de linhas de stacktrace repetido. Menos pior do que um loop infinito, mas ainda assim uma ferramenta muito útil para alguém atacar um servidor. :twisted:
[quote=victorwss]
Bem, acabei de testar aqui (Java Hotspot Client VM, versão 1.6.0_22) para ver o que acontecia. Deu um StackOverflowError após ele gerar centenas de linhas de stacktrace repetido. Menos pior do que um loop infinito, mas ainda assim uma ferramenta muito útil para alguém atacar um servidor. :twisted:[/quote]
Aí sim heim… bem melhor kkkkkk
Nem me impressiono tanto… quando mexia com C tinha coisa bem pior
Pessoal, só a título de aprendizado com relação a esse bug, se houvessem testes unitários automatizados utilizando as condições de fronteira (valores mínimos, máximos e imediatamente anteriores e posteriores) isso não poderia ter sido evitado? Esse bug pode ser considerado uma prova de que a Sun não utiliza/utilizou testes unitários automatizados em sua base de código?
[quote=dmitsuo]Pessoal, só a título de aprendizado com relação a esse bug, se houvessem testes unitários automatizados utilizando as condições de fronteira (valores mínimos, máximos e imediatamente anteriores e posteriores) isso não poderia ter sido evitado? Esse bug pode ser considerado uma prova de que a Sun não utiliza/utilizou testes unitários automatizados em sua base de código?
[/quote]
Teoricamente esse tipo de erro deveria ter sido capturado no TCK, que é o teste de compatibilidade da plataforma Java, mas aparentemente os caras não testavam o código mesmo.
Imagina só, um erro tão bobo demorou mais de 15 anos para ser descoberto (desconsiderando o bugtraq da sun claro :).
Passei um calafrio danado agora… só de ver isto passou pela minha cabeça todos os sites q fiz, mas ainda bem que pelo q eu recordo não há nenhum parametro do tipo double, integers/ids há as pancadas como é óbvio, só falta algum ID estar sendo validado com o parseDouble… ai eu corto os pulsos!!!
Bem, se os servidores começarem a dar problemas já sei q poderá ser disto…
Aqui no guj esta tudo seguro? :twisted:
O q vai ter de neguinho tentando travar os sites em Java por ai…
Espero q os meus queridos colegas fanáticos em .Net não venham me encher o sako com isto! Se bem que o .Net tb tem bugs arcáicos não resolvidos, mas não imaginava q o Java estivesse assim tb, eu pelo menos acho que nunca encontrei um bug, é q na verdade até posso ter encontrado um ou outro e pensado q o problema era do código…
Um bug realmente existe, mas existe também um problema de interpretação matemática. O código abaixo roda normalmente e o parser também funciona, observer o comentário que coloquei no código.
Eu recomendo relamente validar e usar o BigDecimal para tratar formularios web, pois o caso acima realmente não evita um ataque ao server se vc estiver usando o parse double para valores científicos.
Testei no Netbean 6.9.1 e funciona normalmente como a saida abaixo. RECOMENDO NAO TENTAR DEPURAR O CODIGO ABAIXO, POIS VAI TRAVAR O IDE.
/**
* Atencao nas casas decimais a direita do ponto,
* a declaracao abaixo, 22250738585072014E-324, equivale extamente
* ao numero 2.225073858507201E-308, mas observe que
* 2.2250738585072012 eh diferente de 22250738585072012.
* O motivo eh a limitacao do expoente -308, sendo que com
* 2.2250738585072012 temos 16 casas apos o ponto, logo extrapola
* o limite do double.
* Exemplo para 2.50e-5 e 250e-7 que sao o mesmo numero
* 0.0000250
*/
double x = 22250738585072014E-324;
System.out.println("X: " + x);
String v = String.valueOf(x);
// o parser ocorre sem problemas, pois a representacao esta no limite
// do couble.
double y = Double.parseDouble(v);
System.out.println("Y1: " + y);
// aqui tambem ocorre normalmente pois ainda esta no limite do double
y = Double.parseDouble("22250738585072014E-324");
System.out.println("Y2: " + y);
double z = Double.MIN_NORMAL;
System.out.println("Z: double MIN_NORMAL: " + z);
// operacao ocorre normalmente
double w = x - y;
/**
* convesrao sem problema feita pelo BigDecimal
*/
BigDecimal b = new BigDecimal("2.2250738585072012e-308");
System.out.println("B: " + b);
/**
* A T E N C A O
* a chamada abaixo vai dar problema pois nao ha como
* representar o numero acima em double.
*/
//System.out.println("B: " + b.doubleValue());
System.out.println("W: " + w);
A Oracle também já lançou updates pro JDK deles e um patch manual pra quem quiser aplicar. Fizeram um post dando umas desculpinhas pra não terem corrigido antes, já que o bug existe desde 2001:
No entanto, se você clicar neste link aí em cima, verá que ele não funciona. Quando a Oracle comprou a Sun, vários bugs cadastrados “misteriosamente” sumiram.
Bem, que eu saiba ele não foi consertado até hoje (na época a sun recusou o bug como sendo algo “não importante”). Trata-se do seguinte:
Throwable a = new Throwable();
Throwable b = new Throwable(a);
a.initCause(b);
a.printStackTrace(); // Loop infinito!
Imagina o que acontece se um hacker serializa a exceção para o servidor e o servidor faz o log dela?[/quote]
O que vc estava tentando fazer para descobrir isto? :shock: :shock: :shock:
No entanto, se você clicar neste link aí em cima, verá que ele não funciona. Quando a Oracle comprou a Sun, vários bugs cadastrados “misteriosamente” sumiram.
Bem, que eu saiba ele não foi consertado até hoje (na época a sun recusou o bug como sendo algo “não importante”). Trata-se do seguinte:
Throwable a = new Throwable();
Throwable b = new Throwable(a);
a.initCause(b);
a.printStackTrace(); // Loop infinito!
Imagina o que acontece se um hacker serializa a exceção para o servidor e o servidor faz o log dela?[/quote]
O que vc estava tentando fazer para descobrir isto? :shock: :shock: :shock:
[/quote]
Ele estava tentando descobrir o que a JVM faz quando uma exceção culpa a outra!
Ele estava tentando descobrir o que a JVM faz quando uma exceção culpa a outra! [/quote]
então estava só brincando… agora ta explicado o porque a sun recusou… pela própria natureza do negocio isto iria estourar a pilha,
é a mesma coisa que vc colocar 2 espelhos um refletindo o outro e querer que só um deles reflita e o outro não…
