1

According this topic: Reasons of getting a java.lang.VerifyError

java.lang.VerifyError obtains if version of execution jvm newer than jvm that was used for compilation.

Always we can fix this problem using following jvm option: -XX:-UseSplitVerifier.

According this:

https://stackoverflow.com/a/16467026/2674303

to use this option is 'perfectly safe'.

Thus I don't understand why does java.lang.VerifyError is problem that prevents succesful compilation. Please clarify. Maybe it is not safe for libraries which instrument bytecode?

Community
  • 1
  • 1
gstackoverflow
  • 36,709
  • 117
  • 359
  • 710
  • 2
    It doesn't "prevent" successful compilation. Rather, compilation was somehow unsuccessful/erroneous, causing the VerifyError. In essence, the .class file appears to be corrupted. – Hot Licks Sep 28 '14 at 12:54
  • (But the referenced thread talks about using an option that causes the JVM to use the old verifier rather than the "improved" one. It's not clear whether the problem being circumvented is in the class file (in the StackMapTable construction) or in the new verifier (using that table), but in either case the circumvention should be perfectly safe.) – Hot Licks Sep 28 '14 at 13:13

4 Answers4

5

The Q&A's that you link to refer to a specific kind of verification error that it is safe to work around by using an alternative verifier. However, there are other kinds of verify error that you should not ignore ... and that you cannot deal with that way.

In short, the advice in the linked question does not apply in general. In general:

  • Switching to the alternative verifier probably won't help.

  • If you disable the verifier entirely, you risk running code that may violate the JVM's runtime type-safety (etc) constraints. That can lead to security issues and / or heap corruption and hard JVM crashes.

If you have a specific VerifyError that you need advice on, please include the full exception message and stacktrace, and describe the situation in which it occurs. Note that Andrey's answer is correct that a common cause of verification errors is bugs in code that is doing "bytecode engineering" for various purposes. Often, the fix is to change to a different version of the corresponding dependency.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • And ideally, post the offending classfile as well. – Antimony Sep 28 '14 at 16:30
  • Thus this option is not so safe.Even if you use it in correspond situation it can hide future mistakes. – gstackoverflow Sep 28 '14 at 17:41
  • 1
    It might be worth noting that the option `-XX:-UseSplitVerifier` is not supported in Java 8 anymore and will be completely ignored. So it can’t fix anything. – Holger Sep 29 '14 at 17:12
2

VerifyError happens when your byte code is incorrect in some way. For example, when it tries to read from an uninitialized variable or assigns a primitive value to a field of type Object. An instrumentation library may have bugs leading to generation of such malformed bytecode. If you can share the exact details of the error, we could probably be more specific about the exact cause.

Andrey Breslav
  • 24,795
  • 10
  • 66
  • 61
1

The goal is to force tools and libraries generate correct StackMapTable attribute whenever they manipulate Java bytecode, so that JVM does not have to do slow and complicated type inferencing phase of verification, but rather do only fast and simple type checking phase.

-XX:-UseSplitVerifier has been deprecated in Java 8, it won't help any more.

apangin
  • 92,924
  • 10
  • 193
  • 247
1

VerifyError is thrown during class loading by JVM, so it appears on runtime level, not compile level.

  1. Not always we can fix probem by using old verifier. There is a particular case when this helps. It only helps when class is propher for older verifier and is missing StackMapTable which was introduced in JVM 1.6 and are obligatory in JVM 1.7

  2. If you want to get rid VerifyError and UseSplitVerifier does not help that mean that your class is incorrect from JVM point of view. You can still turn off whole verification, but this can cause problems.

  3. Bytecode manipulation is always danger when you don't know what are your'e doing. Now main bytecode manipulation libraries support StackMapFrames calculations so they could generate bytecode which is propher for every VM. But still, user can generate bytecode which is incorrect on class file level, in that case JVM will still thrown VerifyError on load, SplitVerifier won't help. Only disabling verification will force VM to load that class, but could be some error when it will be executing.

Grzesuav
  • 459
  • 2
  • 10