Re: RFR: 8333748: javap crash - Fatal error: Unmatched bit position 0x2 for location CLASS [v2]
On Mon, 17 Jun 2024 13:55:50 GMT, Chen Liang wrote: >> `javap` should never silently ignore erroneous class file content. >> If the flag value violates JVMS - it should be reported as an error and >> `javap` should reflect that in the return value. >> On the other hand `javap` should handle such situations, provide relevant >> error message and continue with the report. >> It is similar case as `javap` detection of inappropriate CP entry types. > > @asotona Thanks for the note, I have updated the code so javap now behaves > like your suggestion. @liach , please file a CSR for this issue to discuss the behavioral changes. - PR Comment: https://git.openjdk.org/jdk/pull/19708#issuecomment-2173914440
Re: RFR: 8333748: javap crash - Fatal error: Unmatched bit position 0x2 for location CLASS [v2]
On Mon, 17 Jun 2024 09:19:22 GMT, Adam Sotona wrote: >> Chen Liang has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - I am a dumbass >> - Retain strict flag for Method, even though it's obsolete > > `javap` should never silently ignore erroneous class file content. > If the flag value violates JVMS - it should be reported as an error and > `javap` should reflect that in the return value. > On the other hand `javap` should handle such situations, provide relevant > error message and continue with the report. > It is similar case as `javap` detection of inappropriate CP entry types. @asotona Thanks for the note, I have updated the code so javap now behaves like your suggestion. - PR Comment: https://git.openjdk.org/jdk/pull/19708#issuecomment-2173462470
Re: RFR: 8333748: javap crash - Fatal error: Unmatched bit position 0x2 for location CLASS [v2]
On Fri, 14 Jun 2024 17:02:40 GMT, Chen Liang wrote: >> Currently, javap crashes for class files that have set non-zero values for >> undefined access flag bits, as >> `java.lang.reflect.AccessFlag.maskToAccessFlag` and >> `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS, though >> asking for these bits to be set to 0, requires VM to proceed and ignore >> these bits. javap should emulate the VM behavior and proceed rendering, >> ignoring these undefined bits. >> >> In addition, a few bytecode generation utilities in the JDK set unused bits, >> such as in >> `java.lang.invoke.MethodHandleImpl.BindCaller#generateInvokerTemplate` and >> `java.lang.invoke.GenerateJLIClassesHelper#generateCodeBytesForLFs`. Those >> can be updated in a later cleanup. > > Chen Liang has updated the pull request incrementally with two additional > commits since the last revision: > > - I am a dumbass > - Retain strict flag for Method, even though it's obsolete `javap` should never silently ignore erroneous class file content. If the flag value violates JVMS - it should be reported as an error and `javap` should reflect that in the return value. On the other hand `javap` should handle such situations, provide relevant error message and continue with the report. It is similar case as `javap` detection of inappropriate CP entry types. - PR Comment: https://git.openjdk.org/jdk/pull/19708#issuecomment-2172842079
Re: RFR: 8333748: javap crash - Fatal error: Unmatched bit position 0x2 for location CLASS [v2]
> Currently, javap crashes for class files that have set non-zero values for > undefined access flag bits, as > `java.lang.reflect.AccessFlag.maskToAccessFlag` and > `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS, though > asking for these bits to be set to 0, requires VM to proceed and ignore these > bits. javap should emulate the VM behavior and proceed rendering, ignoring > these undefined bits. > > In addition, a few bytecode generation utilities in the JDK set unused bits, > such as in > `java.lang.invoke.MethodHandleImpl.BindCaller#generateInvokerTemplate` and > `java.lang.invoke.GenerateJLIClassesHelper#generateCodeBytesForLFs`. Those > can be updated in a later cleanup. Chen Liang has updated the pull request incrementally with two additional commits since the last revision: - I am a dumbass - Retain strict flag for Method, even though it's obsolete - Changes: - all: https://git.openjdk.org/jdk/pull/19708/files - new: https://git.openjdk.org/jdk/pull/19708/files/1cf092f4..84506788 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=19708=01 - incr: https://webrevs.openjdk.org/?repo=jdk=19708=00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19708.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19708/head:pull/19708 PR: https://git.openjdk.org/jdk/pull/19708
