81,091
社区成员
发帖
与我相关
我的任务
分享一个奇怪的问题，请各位老大帮忙看看是什么错
java.lang.VerifyError: (class: _nec_0lease/_sales_0front/_make_0inquiries/_slpo00703_001__jsp, method: _jspService signature: (Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V) Illegal target of jump or branch
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:1590)
at java.lang.Class.getConstructor0(Class.java:1762)
at java.lang.Class.newInstance0(Class.java:276)
at java.lang.Class.newInstance(Class.java:259)
at com.caucho.jsp.JspManager.loadClass(JspManager.java:280)
at com.caucho.jsp.JavaGenerator.compile(JavaGenerator.java:2853)
at com.caucho.jsp.JspGenerator.generate(JspGenerator.java:322)
at com.caucho.jsp.JspParser.parse(JspParser.java:329)
at com.caucho.jsp.JspParser.parse(JspParser.java:234)
at com.caucho.jsp.JspManager.createPage(JspManager.java:172)
at com.caucho.jsp.PageManager.getPage(PageManager.java:351)
at com.caucho.jsp.PageManager.getPage(PageManager.java:206)
at com.caucho.jsp.QServlet.getPage(QServlet.java:220)
at com.caucho.server.http.FilterChainPage.doFilter(FilterChainPage.java:129)
at com.caucho.server.http.Invocation.service(Invocation.java:315)
at com.caucho.server.http.QRequestDispatcher.forward(QRequestDispatcher.java:222)
at com.caucho.server.http.QRequestDispatcher.forward(QRequestDispatcher.java:103)
at com.caucho.server.http.QRequestDispatcher.forward(QRequestDispatcher.java:80)
at jp.co.intra_mart.framework.base.service.DefaultTransition.transfer(DefaultTransition.java:160)
at jp.co.nec_lease.imart.common.base.service.BaseTransition.executeTransfer(BaseTransition.java:33)
at jp.co.nec_lease.imart.common.base.service.BaseTransition.transfer(BaseTransition.java:69)
at jp.co.intra_mart.framework.base.service.ServiceServlet.execute(ServiceServlet.java:321)
at jp.co.intra_mart.framework.base.service.ServiceServlet.doGet(ServiceServlet.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:126)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:103)
at com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.java:96)
at jp.co.intra_mart.framework.base.session.SessionFilter.doFilter(SessionFilter.java:133)
at com.caucho.server.http.FilterChainFilter.doFilter(FilterChainFilter.java:88)
at jp.co.intra_mart.framework.base.service.FileUploadFilter.doFilter(FileUploadFilter.java:75)
at com.caucho.server.http.FilterChainFilter.doFilter(FilterChainFilter.java:88)
at jp.co.intra_mart.framework.base.service.EncodingFilter.doFilter(EncodingFilter.java:119)
at com.caucho.server.http.FilterChainFilter.doFilter(FilterChainFilter.java:88)
at com.caucho.server.http.Invocation.service(Invocation.java:315)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:246)
at com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java:163)
at com.caucho.server.TcpConnection.run(TcpConnection.java:139)
at java.lang.Thread.run(Thread.java:536)
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:1590)
at java.lang.Class.getConstructor0(Class.java:1762)
at java.lang.Class.newInstance0(Class.java:276)
at java.lang.Class.newInstance(Class.java:259)
at com.caucho.jsp.JspManager.loadClass(JspManager.java:280)
at com.caucho.jsp.JavaGenerator.compile(JavaGenerator.java:2853)
at com.caucho.jsp.JspGenerator.generate(JspGenerator.java:322)
at com.caucho.jsp.JspParser.parse(JspParser.java:329)
at com.caucho.jsp.JspParser.parse(JspParser.java:234)
at com.caucho.jsp.JspManager.createPage(JspManager.java:172)
at com.caucho.jsp.PageManager.getPage(PageManager.java:351)
at com.caucho.jsp.PageManager.getPage(PageManager.java:206)
at com.caucho.jsp.QServlet.getPage(QServlet.java:220)
at com.caucho.server.http.FilterChainPage.doFilter(FilterChainPage.java:129)
at com.caucho.server.http.Invocation.service(Invocation.java:315)
at com.caucho.server.http.QRequestDispatcher.forward(QRequestDispatcher.java:222)
at com.caucho.server.http.QRequestDispatcher.forward(QRequestDispatcher.java:103)
at com.caucho.server.http.QRequestDispatcher.forward(QRequestDispatcher.java:80)
at jp.co.intra_mart.framework.base.service.DefaultTransition.transfer(DefaultTransition.java:160)
at jp.co.nec_lease.imart.common.base.service.BaseTransition.executeTransfer(BaseTransition.java:33)
at jp.co.nec_lease.imart.common.base.service.BaseTransition.transfer(BaseTransition.java:69)
at jp.co.intra_mart.framework.base.service.ServiceServlet.execute(ServiceServlet.java:321)
at jp.co.intra_mart.framework.base.service.ServiceServlet.doGet(ServiceServlet.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:126)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:103)
at com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.java:96)
at jp.co.intra_mart.framework.base.session.SessionFilter.doFilter(SessionFilter.java:133)
at com.caucho.server.http.FilterChainFilter.doFilter(FilterChainFilter.java:88)
at jp.co.intra_mart.framework.base.service.FileUploadFilter.doFilter(FileUploadFilter.java:75)
at com.caucho.server.http.FilterChainFilter.doFilter(FilterChainFilter.java:88)
at jp.co.intra_mart.framework.base.service.EncodingFilter.doFilter(EncodingFilter.java:119)
at com.caucho.server.http.FilterChainFilter.doFilter(FilterChainFilter.java:88)
at com.caucho.server.http.Invocation.service(Invocation.java:315)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:246)
at com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java:163)
at com.caucho.server.TcpConnection.run(TcpConnection.java:139)
at java.lang.Thread.run(Thread.java:536)
...全文
请发表友善的回复…
发表回复
litestar 2004-12-29
- 打赏
- 举报
我也没办法，设计不是我们做的。jsp还是小的，我们用的是mvc结构的，我的一个java文件有222K呢。
tom2005 2004-12-29
- 打赏
- 举报
170K左右，这么大
还没有写过这么的文件呢
在java中方法有64k限制
文件太大不好测试，也不好说
还没有写过这么的文件呢
在java中方法有64k限制
文件太大不好测试，也不好说
litestar 2004-12-29
- 打赏
- 举报
to: tom2005
有什么解决方法吗？前提是不能拆分jsp
有什么解决方法吗？前提是不能拆分jsp
tom2005 2004-12-29
- 打赏
- 举报
代码块有大小限制
halfdream 2004-12-29
- 打赏
- 举报
关注。。
litestar 2004-12-29
- 打赏
- 举报
to loverisyour:我也没有用什么方法，只是我的jsp文件有4000多行，170K左右，随便删掉一段代码，让程序短一些，就OK了。是不是JDK1.4支持不了这么大的文件呢？
loverisyour 2004-12-28
- 打赏
- 举报
The secret of unverified code
When the JVM loads a class file from a server across the network, it has no way of knowing whether or not the byte code is safe to execute. Safe byte code never instructs the virtual machine to perform operations that would leave the Java runtime in an inconsistent or invalid state.
Normally the Java compiler ensures that the byte code in the class files it creates is safe. It's possible to create byte code by hand that attempts to accomplish tasks Sun's Java compiler would never let you do. The Java verifier examines all such application byte code and, using a fancy set of heuristics, identifies code that doesn't play by the rules. Once byte code is verified, the virtual machine knows that it's safe to execute -- at least as long as the verifier is functioning correctly.
Let's take a look at an example in order to better understand the role the verifier plays and to see why trouble reigns when it fails to function.
Consider the following class:
public
class Test1
{
public
static
void
main(String [] arstring)
{
Float a = new Float(56.78);
Integer b = new Integer(1234);
System.out.println(a.toString());
}
}
If you compile and run that class, the application will print the string 56.78 to the console. That is the value assigned to the instance of the Float class. We are going to modify one byte of the class's byte code and attempt to trick the virtual machine into invoking the toString() method on Integer class's instance rather than on Float's instance (you can download the original and the modified class files from Resources).
Let's take a look at the disassembled output of the unmodified class file:
Method void main(java.lang.String[])
0 new #3
3 dup
4 ldc2_w #13
7 invokespecial #8
10 astore_1
11 new #4
14 dup
15 sipush 1234
18 invokespecial #9
21 astore_2
22 getstatic #10
25 aload_1
26 invokevirtual #12
29 invokevirtual #11
32 return
The listing above contains the main() method's disassembled output. At byte code offset 25 in this method, the virtual machine loads a reference to an instance of Float that was created earlier (at offsets 0 to 10). That is the instruction we will modify. The disassembled output of the modified class is below:
Method void main(java.lang.String[])
0 new #3
3 dup
4 ldc2_w #13
7 invokespecial #8
10 astore_1
11 new #4
14 dup
15 sipush 1234
18 invokespecial #9
21 astore_2
22 getstatic #10
25 aload_2
26 invokevirtual #12
29 invokevirtual #11
32 return
The class is identical byte for byte except for the instruction at offset 25, which loads a reference to an instance of the Integer class.
It is important to note that the result is still valid byte code, meaning the JVM can still execute the byte code without dumping core or heading off into space. The verifier, however, can tell that something has changed under the hood. On my system, I receive the following error when I try to load the class:
Exception in thread "main" java.lang.VerifyError:
(class: Test1, method: main signature: ([Ljava/lang/String;)V)
Incompatible object argument for function call
If you turn the verifier off or if you could exploit a virtual machine flaw and pass the code by the verifier in systems in the wild, the illegal and possibly subversive code works. If I execute the command below I receive the answer 1234 -- the value of the Integer instance.
java -noverify Test1
That example is as innocuous as can be, but the potential for harm is real enough. Techniques like those presented above, in conjunction with a virtual machine flaw that allows unverified code to be executed, make type confusion exploits possible.
When the JVM loads a class file from a server across the network, it has no way of knowing whether or not the byte code is safe to execute. Safe byte code never instructs the virtual machine to perform operations that would leave the Java runtime in an inconsistent or invalid state.
Normally the Java compiler ensures that the byte code in the class files it creates is safe. It's possible to create byte code by hand that attempts to accomplish tasks Sun's Java compiler would never let you do. The Java verifier examines all such application byte code and, using a fancy set of heuristics, identifies code that doesn't play by the rules. Once byte code is verified, the virtual machine knows that it's safe to execute -- at least as long as the verifier is functioning correctly.
Let's take a look at an example in order to better understand the role the verifier plays and to see why trouble reigns when it fails to function.
Consider the following class:
public
class Test1
{
public
static
void
main(String [] arstring)
{
Float a = new Float(56.78);
Integer b = new Integer(1234);
System.out.println(a.toString());
}
}
If you compile and run that class, the application will print the string 56.78 to the console. That is the value assigned to the instance of the Float class. We are going to modify one byte of the class's byte code and attempt to trick the virtual machine into invoking the toString() method on Integer class's instance rather than on Float's instance (you can download the original and the modified class files from Resources).
Let's take a look at the disassembled output of the unmodified class file:
Method void main(java.lang.String[])
0 new #3
3 dup
4 ldc2_w #13
7 invokespecial #8
10 astore_1
11 new #4
14 dup
15 sipush 1234
18 invokespecial #9
21 astore_2
22 getstatic #10
25 aload_1
26 invokevirtual #12
29 invokevirtual #11
32 return
The listing above contains the main() method's disassembled output. At byte code offset 25 in this method, the virtual machine loads a reference to an instance of Float that was created earlier (at offsets 0 to 10). That is the instruction we will modify. The disassembled output of the modified class is below:
Method void main(java.lang.String[])
0 new #3
3 dup
4 ldc2_w #13
7 invokespecial #8
10 astore_1
11 new #4
14 dup
15 sipush 1234
18 invokespecial #9
21 astore_2
22 getstatic #10
25 aload_2
26 invokevirtual #12
29 invokevirtual #11
32 return
The class is identical byte for byte except for the instruction at offset 25, which loads a reference to an instance of the Integer class.
It is important to note that the result is still valid byte code, meaning the JVM can still execute the byte code without dumping core or heading off into space. The verifier, however, can tell that something has changed under the hood. On my system, I receive the following error when I try to load the class:
Exception in thread "main" java.lang.VerifyError:
(class: Test1, method: main signature: ([Ljava/lang/String;)V)
Incompatible object argument for function call
If you turn the verifier off or if you could exploit a virtual machine flaw and pass the code by the verifier in systems in the wild, the illegal and possibly subversive code works. If I execute the command below I receive the answer 1234 -- the value of the Integer instance.
java -noverify Test1
That example is as innocuous as can be, but the potential for harm is real enough. Techniques like those presented above, in conjunction with a virtual machine flaw that allows unverified code to be executed, make type confusion exploits possible.
loverisyour 2004-12-28
- 打赏
- 举报
你使用了未通过验证的代码，在J2ME里面经常有这种错误，可以通过preverify命令来验证，j2se里面嘛，不太了解怎么解决，在网上找到了一点资料，希望能对你有点帮助。
loverisyour 2004-12-28
- 打赏
- 举报
你使用了未通过验证的方法
litestar 2004-12-28
- 打赏
- 举报
自己UP一下
litestar 2004-12-28
- 打赏
- 举报
是因为jsp文件太大吗？不过我现在没有权限将jsp拆分，有没有其他办法解决呢？
tom2005 2004-12-28
- 打赏
- 举报
google 搜一下
有很多，不过都是英文的
I think that it's due to the 64kb method restriction in Java - JSP is putting a lot of code into one method when it makes the java source. - check out the generated .java file
有很多，不过都是英文的
I think that it's due to the 64kb method restriction in Java - JSP is putting a lot of code into one method when it makes the java source. - check out the generated .java file
huguolu 2004-12-28
- 打赏
- 举报
把你的主要错误的词语在百度或CSDN上搜索一下，答案就有了!祝好运!
litestar 2004-12-28
- 打赏
- 举报
补充以下，我用的JDK1.4。服务器是ebuilder
