[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: Incomplete "fake exception" stacktraces
From:       David Holmes <david.holmes () oracle ! com>
Date:       2019-11-05 1:14:41
Message-ID: aaaeeb35-6e1a-75f6-5520-86417bc6c509 () oracle ! com
[Download RAW message or body]

Hi Chris,

Thanks for the explanation. I agree that having exitOnError be a macro 
so that NSK_JVMTI_VERIFY works in that case, would be better.

I suspect I'm hitting an issue in the nsk test infrastructure, but I 
hvae no visibility into what. :(

David

On 5/11/2019 10:58 am, Chris Plummer wrote:
> Hi David,
> 
> The "fake exception" was never meant to give you a stack trace, but only 
> indicate which line the failure happened at. Unfortunately you are hitting:
> 
> void exitOnError(jvmtiError error) {
>         if (!NSK_JVMTI_VERIFY(error)) {
>                 exit(error);
>         }
> }
> 
> So this isn't really the point of failure, just a detection of it after, 
> and buried in a C call. An example of the "fake exception" doing better 
> would be https://bugs.openjdk.java.net/browse/JDK-8224555:
> 
> # ERROR: tc02t001.cpp, 126: line == lines[enterEventsCount] || line == 
> (lines[enterEventsCount] + 1)
> # verified assertion is FALSE
> 
>                 if (!NSK_VERIFY(line == lines[enterEventsCount] ||
>                                 line == (lines[enterEventsCount] + 1))) {
> 
> I haven't looked at NSK_JVMTI_VERIFY yet, but possibly it could do 
> better, and maybe exitOnError would play a role in that (would need to 
> be macroized) so we know who is calling exitOnError().
> 
> Chris
> 
> On 11/4/19 3:10 PM, David Holmes wrote:
>> I'm investigating some JVM TI scenario test failures following a 
>> change I made in hotspot. The log shows:
>>
>> The following fake exception stacktrace is for failure analysis.
>> nsk.share.Fake_Exception_for_RULE_Creation: (jvmti_tools.cpp:683) error
>>         at nsk_lvcomplain(nsk_tools.cpp:172)
>> # ERROR: jvmti_tools.cpp, 683: error
>> #     jvmti error: code=52, name=JVMTI_ERROR_INTERRUPT
>>
>> and that is it. This stacktrace is completely useless as it doesn't 
>> show from where nsk_lvcomplain is called!
>>
>> Does anyone know how this is supposed to work and whether there is 
>> some way for me to get a real stacktrace?
>>
>> Thanks,
>> David
> 
> 

[prev in list] [next in list] [prev in thread] [next in thread]