Incomplete "fake exception" stacktraces
David Holmes
david.holmes at oracle.com
Tue Nov 5 01:14:41 UTC 2019
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
>
>
More information about the serviceability-dev
mailing list