crash in JvmtiExport::post_compiled_method_load

[nezih yigitbasi]

Hi,
We have observed the same issue again on Java 10.0+46. I just wanted to
share the new error file and the jvm args in case these provide additional
information.
hs_err file:
https://gist.github.com/nezihyigitbasi/912fc3e7f2aff933f5828f5e913dae64
jvm args:
https://gist.github.com/nezihyigitbasi/301716e9bbcb272d0c2cbadc45938a68

Thanks!
Nezih

On Wed, May 9, 2018 at 5:45 PM serguei.spitsyn at oracle.com <
serguei.spitsyn at oracle.com> wrote:

> I've added the JVM args list to the bug report description.
>
> Thanks,
> Serguei
>
>
> On 5/9/18 17:21, nezih yigitbasi wrote:
>
> Thanks everyone for their input. Here is the full list of JVM args that
> were used:
> https://gist.github.com/nezihyigitbasi/2cc666dff55c663dbfc157e789a3a6f7
>
> Nezih
>
> 2018-05-09 16:52 GMT-07:00 serguei.spitsyn at oracle.com <
> serguei.spitsyn at oracle.com>:
>
>> Hi Nezih,
>>
>> I've filed this bug:
>>   https://bugs.openjdk.java.net/browse/JDK-8202883
>>     crash in the JvmtiExport::post_compiled_method_load
>>
>> Please, feel free to add any details when you have them.
>> They are very important to reproduce the crash.
>> For instance, what GC was used in scenario with this crash?
>>
>> Thank you for reporting the issue!
>> Serguei
>>
>>
>>
>> On 5/8/18 16:51, serguei.spitsyn at oracle.com wrote:
>>
>> Hi Nezih,
>>
>> Crashing in the JvmtiExport::post_compiled_method_load function
>> does not prove itself that it is a VM issue.
>> And there are mo specific details in the log that help to understand this.
>> Filing a bug with this log is almost useless as it would not help to get
>> to the root cause.
>> Also, there is still a pretty big chance the real problem is in the agent.
>>
>> My advice is to get as more details about this crash as possible.
>> The best you can do is to provide a stand alone test case.
>> Even if the issue is in the agent it will help to figure it out.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 5/8/18 16:38, nezih yigitbasi wrote:
>>
>> Hi Serguei,
>> We don't have a repro unfortunately. We have seen this only once so far
>> in our production environment.
>>
>> Do you think this can be an agent issue? I thought like if it was an
>> agent issue the stack trace would show it. The stack trace, however, ends
>> in the VM code -- the crash happens in the
>> "JvmtiExport::post_compiled_method_load" method.
>>
>> Thanks,
>> Nezih
>>
>> 2018-05-08 16:34 GMT-07:00 serguei.spitsyn at oracle.com <
>> serguei.spitsyn at oracle.com>:
>>
>>> Hi Nezih,
>>>
>>> You error file with log does not help much.
>>> Could you, please, reproduce this issue with the debug or fastdebug
>>> build?
>>> Also, a standalone test case is better to provide to
>>> increase chances the issue to be investigated and fixed.
>>>
>>> In general, a JVMTI agent has to be written very carefully as it can
>>> easily cause the VM to crash.
>>> So, it makes sense to look at the agent implementation first to make
>>> sure it does not do anything wrong.
>>> It is what we normally do first and why a test case that demonstrates
>>> the problem is needed.
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>>
>>> On 5/8/18 16:00, nezih yigitbasi wrote:
>>>
>>> Hi,
>>>
>>> First of all, sorry for bringing up a crash issue in this dev mailing
>>> list, but the crash report submission page (
>>> https://bugreport.java.com/bugreport/crash.jsp) doesn't list Java 9 in
>>> the release drop down, so I couldn't report it there.
>>>
>>> We recently got a crash with Java 9.0.1+11 with an interesting stack
>>> ending at "JvmtiExport::post_compiled_method_load()" (entire error file is
>>> here
>>> <https://gist.github.com/nezihyigitbasi/52a58698cc9acfcab21c69d00bd0cef2>).
>>> A google search didn't end up with much info, so I just wanted to check
>>> with this mailing list to see whether anyone has any ideas to investigate
>>> this further.
>>>
>>> Thanks,
>>> Nezih
>>>
>>>
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181012/f34ea548/attachment-0001.html>