Community
Participate
Working Groups
I have a .jj file that is processed using JavaCC. If these files are compiled using command line javac (with debug on or off) or within Eclipse using Ant, the program runs correctly. However, when compiled using Eclipse, I get an error like the following: Exception in thread "main" java.lang.VerifyError: (class: org/rubato/rubettes/denotex/DenotexParser, method: basicModule signature: ()Lorg/rubato/math/module/Module;) Illegal target of jump or branch Here DenotexParser is the file generated by JavaCC, basicModule is a method generated from a rule in the JavaCC file, that returns an object of class Module.
Which Eclipse build are you using ? Also, can you attach the entire testcase with steps ? A verify error sounds bad. Please reopen defect once requested information is available.
Currently I am running Build id: 200309170800. What do you mean by a testcase. What files/output do you expect that I supply?
We would like to get the source of this class: org.rubato.rubettes.denotex.DenotexParser Ideally it would be great if you could provide enough classes to be able to compile without errors.
I isolated a test case from the same error in the Help component. See attach file. I will investigate to reduce it to a simple test case.
Created attachment 6198 [details] Compile this file using latest head contents We might want to fix this bug before switching compiler for the build.
Created attachment 6199 [details] Simpler test case
Increase severity since we have a test case to reproduce the problem and it seems that the Help component hits the same issue. Here are our bytecodes for the simpler test case: final public void foo(); /* Stack: 1, Locals: 4 */ Code attribute: 0 iconst_0 1 istore_1 2 iconst_0 3 istore_2 4 iconst_0 5 istore_3 6 iload_1 7 tableswitch default: 25 case 0: 24 24 return 25 iload_3 26 ifeq 33 29 return 30 goto 82 <================= THIS IS ILLEGAL 33 iload_1 34 tableswitch default: 53 case 0: 52 52 return 53 iload_2 54 ifeq 61 57 return 58 goto 82 <================= THIS IS ILLEGAL 61 iload_1 62 tableswitch default: 81 case 0: 80 80 return 81 return
Compiled with javac 1.4.1, we get: /* Method descriptor #5 ()V */ final public void foo(); /* Stack: 1, Locals: 4 */ Code attribute: 0 iconst_0 1 istore_1 2 iconst_0 3 istore_2 4 iconst_0 5 istore_3 6 iload_1 7 lookupswitch default: 25 case 0: 24 24 return 25 iload_3 26 ifeq 30 29 return 30 iload_1 31 lookupswitch default: 49 case 0: 48 48 return 49 iload_2 50 ifeq 54 53 return 54 iload_1 55 lookupswitch default: 73 case 0: 72 72 return 73 return
If we look at our bytecode, the two illegal goto are unreachable.
We have a similar issue in help, with one of the JavaCC generated files. I will attach the file with problems, but if you want to run something to reproduce the problem: - extract org.apache.lucene from HEAD - run as "Run-time Workbench" - in the eclipse instance that comes up launch help Help->Help Contents. - after help browser is showing the eclipse books, enter some text in the search entry field and hit go. - you'll see the error in the console: java.lang.VerifyError: (class: org/apache/lucene/demo/html/HTMLParser, method: ArgValue signature: ()Lorg/apache/lucene/demo/html/Token;) Illegal target of jump or branch at org.eclipse.help.internal.search.HTMLDocParser.openDocument (HTMLDocParser.java:74) at org.eclipse.help.internal.search.SearchIndex.addDocument (SearchIndex.java:112) at org.eclipse.help.internal.search.IndexingOperation.addDocuments (IndexingOperation.java:107) at org.eclipse.help.internal.search.IndexingOperation.execute (IndexingOperation.java:88) at org.eclipse.help.internal.search.SearchManager.updateIndex (SearchManager.java:148) at org.eclipse.help.internal.search.SearchManager.search (SearchManager.java:89) at org.eclipse.help.internal.search.SearchProgressMonitor$2.run (SearchProgressMonitor.java:144) at java.lang.Thread.run(Thread.java:536)
Created attachment 6204 [details] JavaCC generated file
Created attachment 6205 [details] Simplest test case ever
Dorian, The simpler test case is extracted from your example. The goto is generated inside the if statement when there is a else statement and the then statement is not considered as returning. I think this is where the bug is coming from. Debugging the simpler test case, it appears that the if statements that generates the illegal gotos are the ones with a condition. if (b1) { if (true) return; } else { switch (i) { case 0 : if (true) return; break; default : if (b) { if (true) return; } else { switch (i) { case 0 : if (true) return; break; default : return; } } } } The then clause of this if if (b1) { if (true) return; } else { is considered as not exiting, but it does. At least the code generation considers that it does. So we need to be consistent. The thenFlowInfo is considered as unreachable. Is this equivalent to a DEAD_END?
Will investigate a fix. It is actually a consequence of another fix for bug 40736.
Bug 40736 was an incorrect diagnosis during flow analysis due to fake reachable code in an IF statement. In order to fix it, I had changed the value of the flag #thenExit to be (flowInfo == DEAD_END) instead of !flowInfo.isReachable(). This behavior gave the proper flow analysis behavior, but broke code gen which did expect the flag to be position whenever the flow info isn't reachable (i.e. truly unreachable or fake reachable). Change is being tested.
Fix integrated. Will soon post a patch of JDTCore in our download area: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core- home/r3.0/main.html#updates Regression tests added.
Confirming patch went out. Will release for integration rebuild.
Verified.
Regression test is InitializationTest#test166
