8234905: [test] TestElfDirectRead fails on ARM32 due to missing call stack information

[Mikhailo Seledtsov]

Hi Christoph,

General recommendation is as follows:
   - if the error can be fixed, place the test on a problem list (follow 
process described by Dan). Problem list supports exclusions per 
platform, as well as general exclusions.
   - if the problem is not fixable (e.g. the test scenario is not 
supported by a given platform or configuration), then use @requires in 
the test header, if possible
      For example:  @requires !(vm.bits == "32" & os.arch == "arm")

Regards,
Misha

On 12/4/19, 7:40 AM, Daniel D. Daugherty wrote:
> Typically you create a subtask of the original bug with a synopsis 
> like this:
>
>     ProblemList runtime/ElfDecoder/TestElfDirectRead.java
>
> and then use that bug to make the update to the ProblemList.txt file.
>
> However, I wonder if the right solution is some @requires directive
> (but I don't know the right one).
>
> Based on what I read in JDK-8234905, it seems like this bug isn't fixable
> in 32-bit ARM in thumb mode. Maybe I'm not reading it right...
>
> Dan
>
>
> On 12/4/19 5:15 AM, christoph.goettschkes at microdoc.com wrote:
>> Hi,
>>
>> I would like to add the test TestElfDirectRead to the ProblemsList (see
>> [1]), because it is failing on 32-bit ARM. The bug report [2] describes
>> why the test is failing and I currently don't see a trivial way to solve
>> this issue. The issue is, that on ARM32 in thumb mode, HotSpot can not
>> retrieve stack frames and hence, the reporting used in the test looks
>> different from the reporting on other platforms.
>>
>> Do I need to create a new JBS issue for the change to the problems list,
>> so the original bug stays open? Please advice.
>>
>> Thanks,
>> Christoph
>>
>> [1]
>> https://cr.openjdk.java.net/~cgo/8234905/webrev.00
>> [2]
>> https://bugs.openjdk.java.net/browse/JDK-8234905
>>
>