Bug estupido.

Ontem eu estava muito contente porque depois de tres fim de semanas de trabalho arduo consegui enfim terminar todas as melhorias que eu tinha planejado para o meu prototipo da minha tese que estou fazendo em java.
Fiz varios testes, dados diferentes, tudo correndo bem, dai tive a brilhante ideia de ter no log as informacoes da thread, fiz um toString bem legal:

public String toString() {
if (thisToString == null) {
StringBuilder sb = new StringBuilder(this.hashCode());
sb.append("-");
sb.append(databank.toString());
thisToString = sb.toString();
}
return thisToString;
}

Testei umas vezes, achei que estava um pouco mais lento que o normal, mas nao dei bola, gerei o jar, e mandei para o servidor que uso de teste. Continuei achando que estava um mais lento que o normal, culpei o servidor e fui dormir tranquilo.

Hoje durante o dia fui algumas vezes ver como estava rodando e percebia que estava bem mais lento que o comum. Por exemplo, o processo todo ocorria em 90% dos casos em menos de 1 segundo e em mais de 50% em menos de 600milli segundos. Hoje dificilmente executava em menos de 3 segundos. Puta que pariu, tem algo de estranho ai.
Chegando hoje do google, sentei no computador e comecei a depurar, coloquei a culpa no esquema de fila de execucao que usa o ExecutorService que comecei a usar ontem, gastei uma hora nisso e nada… entao coloquei culpa no windows: “Essa merda fica fazendo IO a toa, o scheduler esta louco” e outras disculpas que se inventa.

Cheguei no linux, eclipse, netbeans, console… algo de estranho aconteceu, ao inves ficar lento, simplesmete dava o erro de falta de memoria. Puta que pariu de novo, os parametros estao errados… arrumei, ou nao, porque estavam certos, e voltei a executar, o erro nao passava.

Dai tive a brilhante ideia de prestar atencao na stack”trance” do OOM. StringBuffer? OutOfMemory ali? Este troco esta bugado, so pode… Atualizei o jdk, jvm, tudo… e continuava.

Entao tive a segunda ideia genial, depurar o codigo e ver porque diabos da OOM ali.
Voltando ao codigo que coloquei antes, a linha que dava erro:
StringBuilder sb = new StringBuilder(this.hashCode());

Puta que pariu de novo! Ele aloca um stringbuffer do tamanho do hash, por algum motivo desconhecido o valor do hash no jvm linux eh gigantesco, “1024180126” enquanto no windows eh menor, da OOM no Linux.
Subtitui a linha defeituosa por algo correto:
StringBuilder sb = new StringBuilder(Integer.toString(this.hashCode()));
e bingo, o que antes demorava 3 segundos, voltou aos 100milli!

Conclusao, ao inves de culpar codigos, SOs e etc… gaste 5 minutos e depure seu programa :-)

One thought on “Bug estupido.

  1. depurar
    de.pu.rar
    (lat med depurare) vtd e vpr 1 Purificar(-se), tornar(-se) puro ou mais puro: “Depurar metais, depurar uma opinião. Louvado seja o Senhor que depura os corações com o martírio” (Coelho Neto). Depurou-se pelo trabalho e pelo altruísmo. vtd 2 Limpar: O lavrador ara e depura o campo. O arrependimento depura-nos de intenções culposas. vtd 3 Não apurar os votos obtidos (por um candidato eleito).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s