On Thu, 2 Jun 2022 11:29:58 GMT, Christian Hagedorn <chaged...@openjdk.org> 
wrote:

>>> Thanks Thomas for doing the testing!
>> 
>> Hi Christian,
>> 
>> I can see no problems on ppcle attributable to your test. However, I may 
>> overlook something since tests are still failing all over the place because 
>> of loom.
>> 
>> I see test errors in TestDwarf on ppcle and x64, however. On x64:
>> 
>> 
>> ----------System.out:(52/5198)----------
>> Command line: 
>> [/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/bin/java -cp 
>> /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/runtime/ErrorHandling/TestDwarf.d:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg/runtime/ErrorHandling:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/test/lib:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/lib:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/javatest.jar:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/jtreg.jar
>>  -Xmx768m -Djava.awt.headless=true 
>> -Djava.util.prefs.userRoot=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_ho
 tspot_tier1_work/tmp 
-Djava.io.tmpdir=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/tmp
 -Dtest.getfreeport.max.tries=40 -ea -esa -Xlog:dwarf=info 
-XX:-CreateCoredumpOnCrash -Xcomp -XX:CICrashAt=1 --version ]
>> [2022-05-24T18:37:00.974121691Z] Gathering output for process 44490
>> [2022-05-24T18:37:02.872100892Z] Waiting for completion for process 44490
>> [2022-05-24T18:37:02.872338192Z] Waiting for completion finished for process 
>> 44490
>> Output and diagnostic info for process 44490 was saved into 
>> 'pid-44490-output.log'
>> [2022-05-24T18:37:02.889455876Z] Waiting for completion for process 44490
>> [2022-05-24T18:37:02.889604189Z] Waiting for completion finished for process 
>> 44490
>> # To suppress the following error report, specify this argument
>> # after -XX: or in .hotspotrc:  SuppressErrorAt=/c1_Compilation.cpp:616
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error 
>> (/sapmnt/sapjvm_work/openjdk/nb/linuxx86_64/jdk-dev/src/hotspot/share/c1/c1_Compilation.cpp:616),
>>  pid=44490, tid=44505
>> #  assert(CICrashAt < 0 || (uintx)_env->compile_id() != (uintx)CICrashAt) 
>> failed: just as planned
>> #
>> # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 
>> 19-internal-adhoc.openjdk.jdk-dev)
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 
>> 19-internal-adhoc.openjdk.jdk-dev, compiled mode, sharing, tiered, 
>> compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x73ca34]  Compilation::~Compilation()+0x84
>> #
>> # CreateCoredumpOnCrash turned off, no core file dumped
>> #
>> # An error report file with more information is saved as:
>> # 
>> /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/hs_err_pid44490.log
>> [1.835s][info][dwarf] Open DWARF file: 
>> /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.debuginfo
>> [1.842s][info][dwarf] Failed to parse the line number program header 
>> correctly.
>> [1.842s][info][dwarf] Failed to process the line number program correctly.
>> [1.842s][info][dwarf] Failed to retrieve file and line number information 
>> for 
>> /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so
>>  at offset: 0x0074176a
>> [1.843s][info][dwarf] Failed to parse the line number program header 
>> correctly.
>> [1.843s][info][dwarf] Failed to process the line number program correctly.
>> [1.843s][info][dwarf] Failed to retrieve file and line number information 
>> for 
>> /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so
>>  at offset: 0x00a05011
>> [1.845s][info][dwarf] Failed to parse the line number program header 
>> correctly.
>> [1.845s][info][dwarf] Failed to process the line number program correctly.
>> [1.845s][info][dwarf] Failed to retrieve file and line number information 
>> for 
>> /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so
>>  at offset: 0x00a05b78
>> [1.849s][info][dwarf] Failed to parse the line number program header 
>> correctly.
>> [1.849s][info][dwarf] Failed to process the line number program correctly.
>> [1.849s][info][dwarf] Failed to retrieve file and line number information 
>> for 
>> /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so
>>  at offset: 0x018d49d3
>> [1.852s][info][dwarf] Failed to parse the line number program header 
>> correctly.
>> [1.852s][info][dwarf] Failed to process the line number program correctly.
>> [1.852s][info][dwarf] Failed to retrieve file and line number information 
>> for 
>> /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so
>>  at offset: 0x018de546
>> [1.855s][info][dwarf] Failed to parse the line number program header 
>> correctly.
>> [1.855s][info][dwarf] Failed to process the line number program correctly.
>> [1.855s][info][dwarf] Failed to retrieve file and line number information 
>> for 
>> /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so
>>  at offset: 0x014d86e9
>> #
>> # Compiler replay data is saved as:
>> # 
>> /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/replay_pid44490.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> 
>> hs_err_file: hs_err_pid44490.log
>> ----------System.err:(15/1242)----------
>> java.lang.RuntimeException: Could not find filename or line number in "V  
>> [libjvm.so+0x74176a]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, 
>> DirectiveSet*)+0x1aa": expected true, was false
>>      at jdk.test.lib.Asserts.fail(Asserts.java:594)
>>      at jdk.test.lib.Asserts.assertTrue(Asserts.java:486)
>>      at TestDwarf.runAndCheck(TestDwarf.java:163)
>>      at TestDwarf.test(TestDwarf.java:99)
>>      at TestDwarf.main(TestDwarf.java:90)
>>      at 
>> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>      at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>      at 
>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>      at java.base/java.lang.Thread.run(Thread.java:1585)
>
> After getting some more logs from @tstuefe, it turns out that they are using 
> GCC 8 in the testing which emits the `.debug_line` section in DWARF 2 format 
> which we do not allow and we bail out during parsing. This lets `TestDwarf` 
> fail. 
> 
> The `.debug_line` section is already handled differently by the parser 
> compared to the other sections. GCC 10 emits DWARF 3 for some reason (even 
> though it should emit DWARF 4 as for the other sections) while GCC 11 emits 
> DWARF 4. Therefore, the parser can handle both DWARF 3 and 4 for 
> `.debug_line`. Having a look at the DWARF 2 spec, it turns out that we can 
> reuse the code for parsing DWARF 3. This allows us to update the version 
> bailout of `.debug_line` to allow DWARF 2 as valid version. I've tested this 
> change by building HotSpot with GCC 8.2 and playing around with it.
> 
> In this process, I've also changed `TestDwarf.java` to skip all its tests if 
> there was a bailout of the parser due to an unsupported DWARF format. I've 
> added some more error logging.
> 
> I've also decided to get rid of UL as discussed before and replaced it by 
> `tty` logging in combination with a new `TraceDwarfLevel` develop flag (for 
> the different log levels).

@chhagedorn Please do not rebase or force-push to an active PR as it 
invalidates existing review comments. All changes will be squashed into a 
single commit automatically when integrating. See [OpenJDK Developers’ 
Guide](https://openjdk.java.net/guide/#working-with-pull-requests) for more 
information.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7126

Reply via email to