Olá pessoal! Encontrei um problema muito estranho ao tentar debugar um projeto meu no Eclipse. Tenho uma classe cujo full qualified name(fqn) é "br.com.autbank.antlr.parser.metrics.JavaTreeParser". Em certo "momento" no …

Eclipse: Debug: lança java.lang.InternalError "name is too long to represent"[Insolúvel]

9 de novembro de 2006 7 respostas

Mantu 9 de novembro de 2006

Olá pessoal!
Encontrei um problema muito estranho ao tentar debugar um projeto meu no Eclipse.
Tenho uma classe cujo [i]full qualified name/i é “br.com.autbank.antlr.parser.metrics.JavaTreeParser”. Em certo “momento” no meu projeto, eu tento criar uma instância desta classe. Quando eu mando o Eclipse dar um Run, o programa roda sem problema algum. Porém, quando tento dar um “Debug”, no momento em que eu tento instanciar a classe referida, olhem só o que o Eclipse me lança:

java.lang.InternalError: name is too long to represent
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
	at br.com.autbank.antlr.metrics.dependency.FileDependencyData.<init>(FileDependencyData.java:77)
	at br.com.autbank.antlr.metrics.dependency.FileDependencyData.<init>(FileDependencyData.java:58)
	at br.com.autbank.antlr.metrics.dependency.ComponentDependencyData.<init>(ComponentDependencyData.java:66)
	at br.com.autbank.antlr.metrics.Metrics.run(Metrics.java:60)
	at br.com.autbank.antlr.Main.metricsMain(Main.java:47)
	at br.com.autbank.antlr.Main.main(Main.java:25)

Só para os senhores não se perderem, é na classe “br.com.autbank.antlr.metrics.dependency.FileDependencyData” que há um método que tenta instanciar um JavaTreeParser.
A julgar pela mensagem, o problema seria o tamanho do fqn da classe. De fato, ao reduzir o nome do pacote, não deu mais este problema.
O que eu quero saber é:
:arrow: Por que este problema só ocorre em modo Debug?
:arrow: Há algum meio de permitir fqns longos?

Obrigado pessoal!

7 Respostas

Sami_Koivu 9 de nov. de 2006

Interessante. Será que é a mesma coisa do que aqui?

http://www.antlr.org:8080/pipermail/antlr-interest/2005-November/014335.html

Mantu 9 de nov. de 2006

É sim, Sami Koivu! Acabei de achar esse link… Muito obrigado de qualquer forma!
Se eu fosse manos anta, tinha buscado no Google antes de postar aqui… Mas, de qq forma, parece que é um bug da JVM, pelo que eu entendi:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6294277
Tem uma JSR de número 045 que especifica um tal de SourceDebugExtension, que seria, por exemplo, uma fonte adicional para ser utilizada no processo de debug, atribuída a um class file. Isso é utilizado pra debugar linguagens não-Java (No meu caso, ANTLR), pra fazer um tipo de mapeamento entre a linguagem não-Java e o Java.
O bug acontece quando esse atributo SourceDebugExtension excede 64K e voce tenta rodar a classe com a jvm setada para debugar. Nesse caso, é lançada aquela exceção maledeta…
O mais curioso é que esse bug já tem pouco mais de 1 ano!!! Pelo amor de Deus!!! Que mancada… :shock: :? :evil:

Giuliano_Mega 10 de nov. de 2006

O problema é que o atributo que armazena a linha do código fonte tem só 16 bits. Esse atributo também é usado para debugar Java, só que encontrar um único .java com mais de 65 mil linhas de código não é lá muito comum, provavalmente por isso eles devem ter dado baixa prioridade ao bug (fora que eles iam ter que mexer na estrutura de atributos da VM, o que pode não ser muito simples).

He he he, curioso que eu já usei esse fato prá marcar “pontos especiais” do código fonte (atribuindo code index 65535). Nunca tinha visto ninguém esbarrar nesse limite.

Abraços,

Sami_Koivu 10 de nov. de 2006

Olá,

É verdade que no atributo LineNumberTable existe essa limitação de 16 bits tanto para linha do código fonte quanto para o pc da instrução bytecode num método.

Mas nesse caso, segundo a descrição do bug o problema não é isso.

E sim trata-se de um caso onde o tamanho do atributo especial SourceDebugExtension que faz “um tipo de mapeamento entre a linguagem não-Java e o Java” é maior do que 16 bits, que na verdade não deveria ser um problema pois o tamanho de um atributo é definido com 32 bits.

[]s,
Sami

Sami_Koivu 10 de nov. de 2006

Ou seja, o SourceDebugExtension contém os mapeamentos em texto unicode, por exemplo:

SMAP
Hi.java
Java
*S Foo
*F
1 Hi.foo
2 Incl.foo
*L
1#1,1:1,1
2#1,4:6,2
1#2,2:2,2
*S Bar
*F
1 Hi.bar
2 Incl.bar
*L
1#1:1
1#2,4:2
3#1,8:6
*E

E quando o tamanho desse texto fica maior do que 65535 bytes, dá problemas.

Giuliano_Mega 10 de nov. de 2006

Oops, verdade. Viajei total - isso que dá não ler a descrição do bug direito. :oops:

O SourceDebugExtension é para guardar os SMAPs. E de fato o length é 32 bits nesse caso.

Abraços,

Giuliano_Mega 10 de nov. de 2006

Digo, pela especificação devia ser 32 bits unsigned, como o restante dos atributos (Sec. 4.7 da especificação).

Abraços,

Criado 9 de novembro de 2006

Ultima resposta 10 de nov. de 2006

Respostas 7

Participantes 3

7 Respostas

Topicos relacionados