Okay.
More details on this.
This is the nmethod locking api:
/ Locks an nmethod so its code will not get removed and it will not
// be made into a zombie, even if it is a not_entrant method. After the
// nmethod becomes a zombie, if CompiledMethodUnload event processing
// needs to be done, then lock_nmethod() is used directly to keep the
// generated code from being reused too early.
class nmethodLocker : public StackObj {
CompiledMethod* _nm;
public:
// note: nm can be NULL
// Only JvmtiDeferredEvent::compiled_method_unload_event()
// should pass zombie_ok == true.
static void lock_nmethod(CompiledMethod* nm, bool zombie_ok = false);
static void unlock_nmethod(CompiledMethod* nm); // (ditto)
nmethodLocker(address pc); // derive nm from pc
nmethodLocker(nmethod *nm) { _nm = nm; lock_nmethod(_nm); }
nmethodLocker(CompiledMethod *nm) {
_nm = nm;
lock(_nm);
}
static void lock(CompiledMethod* method) {
if (method == NULL) return;
lock_nmethod(method);
}
static void unlock(CompiledMethod* method) {
if (method == NULL) return;
unlock_nmethod(method);
}
nmethodLocker() { _nm = NULL; }
~nmethodLocker() {
unlock(_nm);
}
CompiledMethod* code() { return _nm; }
void set_code(CompiledMethod* new_nm) {
unlock(_nm); // note: This works even if _nm==new_nm.
_nm = new_nm;
lock(_nm);
}
};
// QQQ might we make this work from a frame??
nmethodLocker::nmethodLocker(address pc) {
CodeBlob* cb = CodeCache::find_blob(pc);
guarantee(cb != NULL && cb->is_compiled(), "bad pc for a nmethod found");
_nm = cb->as_compiled_method();
lock_nmethod(_nm);
}
// Only JvmtiDeferredEvent::compiled_method_unload_event()
// should pass zombie_ok == true.
void nmethodLocker::lock_nmethod(CompiledMethod* cm, bool zombie_ok) {
if (cm == NULL) return;
if (cm->is_aot()) return; // FIXME: Revisit once _lock_count is
added to aot_method
nmethod* nm = cm->as_nmethod();
Atomic::inc(&nm->_lock_count);
assert(zombie_ok || !nm->is_zombie(), "cannot lock a zombie method");
}
void nmethodLocker::unlock_nmethod(CompiledMethod* cm) {
if (cm == NULL) return;
if (cm->is_aot()) return; // FIXME: Revisit once _lock_count is
added to aot_method
nmethod* nm = cm->as_nmethod();
Atomic::dec(&nm->_lock_count);
assert(nm->_lock_count >= 0, "unmatched nmethod lock/unlock");
}
bool is_locked_by_vm() const { return _lock_count
>0; }
The function is_locked_by_vm() must be used to prevent unloading an
nmethod in use.
But it is used only in the NMethodSweeper by:
NMethodSweeper::process_compiled_method()
called from NMethodSweeper::sweep_code_cache()
called from NMethodSweeper::possibly_sweep()
called from NMethodSweeper::sweeper_loop()
called from sweeper_thread_entry()
called from
CodeCacheSweeperThread::CodeCacheSweeperThread()
called from CompileBroker::make_thread()
called from
CompileBroker::init_compiler_sweeper_threads()
NMethodSweeper::possibly_flush()
called from NMethodSweeper::process_compiled_method()
From the other hand, it seems, the nmethod::make_unloaded() cleans up
the nm->_method value:
// If _method is already NULL the Method* is about to be unloaded,
// so we don't have to break the cycle. Note that it is possible to
// have the Method* live here, in case we unload the nmethod because
// it is pointing to some oop (other than the Method*) being unloaded.
if (_method != NULL) {
// OSR methods point to the Method*, but the Method* does not
// point back!
if (_method->code() == this) {
_method->clear_code(); // Break a cycle
}
_method = NULL; // Clear the method of this dead
nmethod <== !!
}
but it does not care about the nmethod locking api above.
The nmethod::make_unloaded() is called from this method:
// If this oop is not live, the nmethod can be unloaded.
bool nmethod::can_unload(BoolObjectClosure* is_alive, oop* root, bool
unloading_occurred) {
assert(root != NULL, "just checking");
oop obj = *root;
if (obj == NULL || is_alive->do_object_b(obj)) {
return false;
}
// If ScavengeRootsInCode is true, an nmethod might be unloaded
// simply because one of its constant oops has gone dead.
// No actual classes need to be unloaded in order for this to occur.
assert(unloading_occurred || ScavengeRootsInCode, "Inconsistency in
unloading");
make_unloaded(is_alive,
obj); <== !!
return true;
}
In its turn the nmethod::make_unloaded() is called from:
bool nmethod::unload_if_dead_at(RelocIterator* iter_at_oop,
BoolObjectClosure *is_alive, bool unloading_occurred) {
assert(iter_at_oop->type() == relocInfo::oop_type, "Wrong relocation
type");
oop_Relocation* r = iter_at_oop->oop_reloc();
// Traverse those oops directly embedded in the code.
// Other oops (oop_index>0) are seen as part of scopes_oops.
assert(1 == (r->oop_is_immediate()) +
(r->oop_addr() >= oops_begin() && r->oop_addr() < oops_end()),
"oop must be found in exactly one place");
if (r->oop_is_immediate() && r->oop_value() != NULL) {
// Unload this nmethod if the oop is dead.
if (can_unload(is_alive, r->oop_addr(), unloading_occurred)) {
return true;;
}
}
return false;
}
bool nmethod::do_unloading_scopes(BoolObjectClosure* is_alive, bool
unloading_occurred) {
// Scopes
for (oop* p = oops_begin(); p < oops_end(); p++) {
if (*p == Universe::non_oop_word()) continue; // skip non-oops
if (can_unload(is_alive, p, unloading_occurred)) {
return true;
}
}
return false;
}
#if INCLUDE_JVMCI
bool nmethod::do_unloading_jvmci(BoolObjectClosure* is_alive, bool
unloading_occurred) {
bool is_unloaded = false;
// Follow JVMCI method
BarrierSet* bs = Universe::heap()->barrier_set();
if (_jvmci_installed_code != NULL) {
if (_jvmci_installed_code->is_a(HotSpotNmethod::klass()) &&
HotSpotNmethod::isDefault(_jvmci_installed_code)) {
if (!is_alive->do_object_b(_jvmci_installed_code)) {
clear_jvmci_installed_code();
}
} else {
if (can_unload(is_alive, (oop*)&_jvmci_installed_code,
unloading_occurred)) {
return true;
}
}
}
if (_speculation_log != NULL) {
if (!is_alive->do_object_b(_speculation_log)) {
bs->write_ref_nmethod_pre(&_speculation_log, this);
_speculation_log = NULL;
bs->write_ref_nmethod_post(&_speculation_log, this);
}
}
return is_unloaded;
}
#endif
The only caller of the the unload_if_dead_at() and do_unloading_scopes()
is nmethod::do_unloading_oops():
bool nmethod::do_unloading_oops(address low_boundary, BoolObjectClosure*
is_alive, bool unloading_occurred) {
// Compiled code
{
RelocIterator iter(this, low_boundary);
while (iter.next()) {
if (iter.type() == relocInfo::oop_type) {
if (unload_if_dead_at(&iter, is_alive, unloading_occurred)) {
return true;
}
}
}
}
return do_unloading_scopes(is_alive, unloading_occurred);
}
Let's skip AOT part.
Both
nmethod::do_unloading_oops() and
nmethod::do_unloading_jvmci()
called from CompiledMethod::do_unloading()
and CompiledMethod::do_unloading_parallel().
CompiledMethod::do_unloading_parallel()
called from G1CodeCacheUnloadingTask::clean_nmethod()
called from G1CodeCacheUnloadingTask::work_first_pass()
and G1CodeCacheUnloadingTask::work_second_pass()
called from G1ParallelCleaningTask::G1ParallelCleaningTask()
called from G1CollectedHeap::parallel_cleaning()
called from
G1ConcurrentMark::weakRefsWorkParallelPart()
called from G1ConcurrentMark::weakRefsWork()
called from
G1ConcurrentMark::checkpointRootsFinal()
. . .
Now, I'm lost...
It is hard to find out how all these sub-call-tree should transitively
call the NMethodSweeper::process_compiled_method() function which uses
the function is_locked_by_vm() to synchronize with
post_compiled_method_load().
Just some initial (very stupid) analysis... :-)
Thanks,
Serguei
On 5/9/18 01:02, serguei.spit...@oracle.com wrote:
Hi Ioi and David,
Ioi, thank you for the disassembly.
It helps for sure!
Below are 3 call sites for the
nmethod::post_compiled_method_load_event():
void ciEnv::register_method(ciMethod* target, . . .) {
. . .
if (nm != NULL) {
// JVMTI -- compiled method notification (must be done outside lock)
nm->post_compiled_method_load_event(); <== !!
} else {
. . .
}
}
JVMCIEnv::CodeInstallResult JVMCIEnv::register_method(. . .) {
. . .
// JVMTI -- compiled method notification (must be done outside lock)
if (nm != NULL) {
nm->post_compiled_method_load_event(); <== !!
. . .
}
return result;
}
void AdapterHandlerLibrary::create_native_wrapper(const methodHandle&
method) {
. . .
if (nm != NULL) {
. . .
nm->post_compiled_method_load_event(); <== !!
}
}
The nmethod::post_compiled_method_load_event() creates a
JvmtiDeferredEvent
compiled_load_event entry and enqueues it for the ServiceThread
processing.
void nmethod::post_compiled_method_load_event() {
Method* moop = method();
HOTSPOT_COMPILED_METHOD_LOAD(
(char *) moop->klass_name()->bytes(),
moop->klass_name()->utf8_length(),
(char *) moop->name()->bytes(),
moop->name()->utf8_length(),
(char *) moop->signature()->bytes(),
moop->signature()->utf8_length(),
insts_begin(), insts_size());
if (JvmtiExport::should_post_compiled_method_load() ||
JvmtiExport::should_post_compiled_method_unload()) {
get_and_cache_jmethod_id();
}
if (JvmtiExport::should_post_compiled_method_load()) {
// Let the Service thread (which is a real Java thread) post the
event
MutexLockerEx ml(Service_lock, Mutex::_no_safepoint_check_flag);
JvmtiDeferredEventQueue::enqueue(
JvmtiDeferredEvent::compiled_method_load_event(this)); <== !!
}
}
The vmtiDeferredEvent::compiled_method_load_event() below uses
nmethodLocker::lock_nmethod(nm) to protect the nmethod* nm
from being updated:
JvmtiDeferredEvent JvmtiDeferredEvent::compiled_method_load_event(
nmethod* nm) {
JvmtiDeferredEvent event =
JvmtiDeferredEvent(TYPE_COMPILED_METHOD_LOAD);
event._event_data.compiled_method_load =
nm; <== !!
// Keep the nmethod alive until the ServiceThread can process
// this deferred event.
nmethodLocker::lock_nmethod(nm); <== !!
return event;
}
void JvmtiDeferredEventQueue::enqueue(const JvmtiDeferredEvent& event) {
assert(Service_lock->owned_by_self(), "Must own Service_lock");
process_pending_events();
// Events get added to the end of the queue (and are pulled off the
front).
QueueNode* node = new QueueNode(event);
if (_queue_tail == NULL) {
_queue_tail = _queue_head = node;
} else {
assert(_queue_tail->next() == NULL, "Must be the last element in
the list");
_queue_tail->set_next(node);
_queue_tail = node;
}
Service_lock->notify_all();
assert((_queue_head == NULL) == (_queue_tail == NULL),
"Inconsistent queue markers");
}
JvmtiDeferredEvent JvmtiDeferredEventQueue::dequeue() {
assert(Service_lock->owned_by_self(), "Must own Service_lock");
process_pending_events();
assert(_queue_head != NULL, "Nothing to dequeue");
if (_queue_head == NULL) {
// Just in case this happens in product; it shouldn't but let's
not crash
return JvmtiDeferredEvent();
}
QueueNode* node = _queue_head;
_queue_head = _queue_head->next();
if (_queue_head == NULL) {
_queue_tail = NULL;
}
assert((_queue_head == NULL) == (_queue_tail == NULL),
"Inconsistent queue markers");
JvmtiDeferredEvent event = node->event();
delete node;
return event;
}
The ServiceThread (different thread which is a JavaThread)
takes the event from the JvmtiDeferredEventQueue queue
and posts it.
void ServiceThread::service_thread_entry(JavaThread* jt, TRAPS) {
. . .
if (has_jvmti_events) {
jvmti_event = JvmtiDeferredEventQueue::dequeue();
<== !!
}
}
if (has_jvmti_events) {
jvmti_event.post(); <== !!
}
. . .
}
The JvmtiDeferredEvent::post() below makes the call:
JvmtiExport::post_compiled_method_load(nm);
and only then unlocks the nmethod nm with
nmethodLocker::unlock_nmethod(nm).
void JvmtiDeferredEvent::post() {
assert(ServiceThread::is_service_thread(Thread::current()),
"Service thread must post enqueued events");
switch(_type) {
case TYPE_COMPILED_METHOD_LOAD: {
nmethod* nm = _event_data.compiled_method_load;
JvmtiExport::post_compiled_method_load(nm); <== !!
// done with the deferred event so unlock the nmethod
nmethodLocker::unlock_nmethod(nm); <== !!
break;
}
. . .
default:
ShouldNotReachHere();
}
}
The printed disassembly shows where we observe the crash in the
functions below:
void JvmtiExport::post_compiled_method_load(nmethod *nm) {
if (JvmtiEnv::get_phase() < JVMTI_PHASE_PRIMORDIAL) {
return;
}
JavaThread* thread = JavaThread::current();
EVT_TRIG_TRACE(JVMTI_EVENT_COMPILED_METHOD_LOAD,
("[%s] method compile load event triggered",
JvmtiTrace::safe_get_thread_name(thread)));
JvmtiEnvIterator it;
for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) {
if (env->is_enabled(JVMTI_EVENT_COMPILED_METHOD_LOAD)) {
if (env->phase() == JVMTI_PHASE_PRIMORDIAL) {
continue;
}
EVT_TRACE(JVMTI_EVENT_COMPILED_METHOD_LOAD,
("[%s] class compile method load event sent %s.%s ",
JvmtiTrace::safe_get_thread_name(thread),
(nm->method() == NULL) ? "NULL" :
nm->method()->klass_name()->as_C_string(),
(nm->method() == NULL) ? "NULL" :
nm->method()->name()->as_C_string()));
ResourceMark rm(thread);
HandleMark hm(thread);
// Add inlining information
jvmtiCompiledMethodLoadInlineRecord* inlinerecord =
create_inline_record(nm);
// Pass inlining information through the void pointer
JvmtiCompiledMethodLoadEventMark jem(thread, nm,
inlinerecord); <== !!
JvmtiJavaThreadEventTransition jet(thread);
jvmtiEventCompiledMethodLoad callback =
env->callbacks()->CompiledMethodLoad;
if (callback != NULL) {
(*callback)(env->jvmti_external(), jem.jni_methodID(),
jem.code_size(), jem.code_data(), jem.map_length(),
jem.map(), jem.compile_info());
}
}
}
}
class JvmtiCompiledMethodLoadEventMark : public JvmtiMethodEventMark {
. . .
public:
JvmtiCompiledMethodLoadEventMark(JavaThread *thread, nmethod *nm,
void* compile_info_ptr = NULL)
: JvmtiMethodEventMark(thread,methodHandle(thread,
nm->method())) { <== !!
. . .
}
. . .
}
class JvmtiMethodEventMark : public JvmtiThreadEventMark {
. . .
JvmtiMethodEventMark(JavaThread *thread, methodHandle method) :
JvmtiThreadEventMark(thread),
_mid(to_jmethodID(method))
{}; <== line 234 !!
jmethodID jni_methodID() { return _mid; }
};
All the fragments above show the code path correctly operates with
nmethod
by protecting it with the nmethodLocker::lock_nmethod(nm) until the event
has been posted.
There can be several guesses about the above:
- the above is correct but some other code abuses the convention and
updates the nmethod without grabbing the nmethod lock
- the above operations with the nmethod is incorrect (miss some steps)
- some other reason (I doubt it is the case)
One conclusion is that it is unlikely an issue in the JVMTI agent as I
suspected initially.
It would still be valuable to have more details about a scenario that
reproduced this issue.
It is probably enough information to file a bug.
Any opinions on the above?
Any ideas about what can be broken?
Thanks,
Serguei
On 5/8/18 23:00, David Holmes wrote:
On 9/05/2018 3:06 PM, Ioi Lam wrote:
Serguei & Nezih,
I've looked at the crash log and it seems like nm->method() is NULL,
which caused the crash.
I am not familiar with the JVMTI internals or nmethods, so I am just
guessing here -- is it legal for nm->method() to be NULL? Or, is it
possible that someone has cleared nm->method() before it's processed
by post_compiled_method_load?
I was wondering the same thing. Vladimir K. pointed me at:
http://hg.openjdk.java.net/jdk/jdk/file/ae0ebd3cf949/src/hotspot/share/runtime/sweeper.hpp#l42
for the nmethod lifecycle. Given this is actually a deferred event, I
too wonder if the nmethod may have been made not-entrant or even
zombie, since the event was posted.
David
-----
Details from the crash log:
=================================
Native frames: (J=compiled Java code, A=aot compiled Java code,
j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x99e365]
JvmtiExport::post_compiled_method_load(nmethod*)+0x275
V [libjvm.so+0x9a6614] JvmtiDeferredEvent::post()+0x44
V [libjvm.so+0xc2c507]
ServiceThread::service_thread_entry(JavaThread*, Thread*)+0x337
V [libjvm.so+0xceee58] JavaThread::thread_main_inner()+0xd8
V [libjvm.so+0xb6de12] thread_native_entry(Thread*)+0xf2
C [libpthread.so.0+0x7e25] start_thread+0xc5
...
R14=0x0000000000000000 is an unknown value
=================================
Here's a disassembly of JvmtiExport::post_compiled_method_load from
JDK 9.0.1
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/b756e7a2ec33/src/share/vm/prims/jvmtiExport.cpp
2051 HandleMark hm(thread);
0x00007ffff67dd239 <+329>: mov %rax,-0x140(%rbp)
0x00007ffff67dd240 <+336>: callq 0x7ffff66149d0
<HandleMark::initialize(Thread*)>
2054 jvmtiCompiledMethodLoadInlineRecord* inlinerecord =
create_inline_record(nm);
0x00007ffff67dd245 <+341>: mov %r12,%rdi
0x00007ffff67dd248 <+344>: callq 0x7ffff67d4090
<create_inline_record(nmethod*)>
2055 // Pass inlining information through the void pointer
2056 JvmtiCompiledMethodLoadEventMark jem(thread, nm,
inlinerecord);
0x00007ffff67dd24d <+349>: mov %rax,-0x1a8(%rbp)
0x00007ffff67dd254 <+356>: mov 0x70(%r12),%rax
0x00007ffff67dd259 <+361>: mov %rbx,-0x178(%rbp)
0x00007ffff67dd260 <+368>: test %rax,%rax
0x00007ffff67dd263 <+371>: mov %rax,-0x180(%rbp)
0x00007ffff67dd26a <+378>: je 0x7ffff67dd282
<JvmtiExport::post_compiled_method_load(nmethod*)+402>
0x00007ffff67dd26c <+380>: mov %rax,-0xa0(%rbp)
0x00007ffff67dd273 <+387>: mov 0x160(%rbx),%rdi
0x00007ffff67dd27a <+394>: mov %r13,%rsi
0x00007ffff67dd27d <+397>: callq 0x7ffff671d5f0
<GrowableArray<Metadata*>::append(Metadata* const&)>
0x00007ffff67dd282 <+402>: lea 0x218(%rbx),%rax
0x00007ffff67dd289 <+409>: mov %rbx,-0xf0(%rbp)
0x00007ffff67dd290 <+416>: movl $0x0,-0xe0(%rbp)
0x00007ffff67dd29a <+426>: mov %rax,-0xe8(%rbp)
0x00007ffff67dd2a1 <+433>: mov 0x3c8(%rbx),%rax
0x00007ffff67dd2a8 <+440>: test %rax,%rax
0x00007ffff67dd2ab <+443>: je 0x7ffff67dd2b6
<JvmtiExport::post_compiled_method_load(nmethod*)+454>
0x00007ffff67dd2ad <+445>: mov 0x10(%rax),%eax
0x00007ffff67dd2b0 <+448>: mov %eax,-0xe0(%rbp)
0x00007ffff67dd2b6 <+454>: mov 0x38(%rbx),%r14
0x00007ffff67dd2ba <+458>: mov %rbx,%rdi
0x00007ffff67dd2bd <+461>: callq 0x7ffff6707d50
<JNIHandleBlock::allocate_block(Thread*)>
0x00007ffff67dd2c2 <+466>: lea 0x1f8(%rbx),%rdi
0x00007ffff67dd2c9 <+473>: mov %rbx,%rsi
0x00007ffff67dd2cc <+476>: mov %r14,0x118(%rax)
0x00007ffff67dd2d3 <+483>: mov %rax,0x38(%rbx)
0x00007ffff67dd2d7 <+487>: callq 0x7ffff6559410
<JavaFrameAnchor::make_walkable(JavaThread*)>
0x00007ffff67dd2dc <+492>: mov 0x1f0(%rbx),%rsi
0x00007ffff67dd2e3 <+499>: mov -0xf0(%rbp),%rdi
0x00007ffff67dd2ea <+506>: callq 0x7ffff6708520
<JNIHandles::make_local(Thread*, oopDesc*)>
0x00007ffff67dd2ef <+511>: mov -0x1a0(%rbp),%rsi
0x00007ffff67dd2f6 <+518>: mov %rax,-0xd8(%rbp)
0x00007ffff67dd2fd <+525>: lea -0x170(%rbp),%rax
0x00007ffff67dd304 <+532>: mov %rax,%rdi
0x00007ffff67dd307 <+535>: mov %rax,-0x1b0(%rbp)
// JvmtiMethodEventMark(JavaThread *thread, methodHandle method) :
// JvmtiThreadEventMark(thread),
234 _mid(to_jmethodID(method)) {}; <-- this line
0x00007ffff67dd30e <+542>: callq 0x7ffff66140a0
<methodHandle::methodHandle(methodHandle const&)>
0x00007ffff67dd313 <+547>: mov -0x170(%rbp),%r14
0x00007ffff67dd31a <+554>: movq $0x0,-0x98(%rbp)
0x00007ffff67dd325 <+565>: test %r14,%r14
0x00007ffff67dd328 <+568>: mov %r14,-0xa0(%rbp)
0x00007ffff67dd32f <+575>: je 0x7ffff67dd365
<JvmtiExport::post_compiled_method_load(nmethod*)+629>
0x00007ffff67dd331 <+577>: data16 lea
0x946ca7(%rip),%rdi # 0x7ffff7123fe0
0x00007ffff67dd339 <+585>: data16 data16 callq 0x7ffff60b11d0
<__tls_get_addr@plt>
0x00007ffff67dd341 <+593>: lea -0x188(%rbp),%rsi
0x00007ffff67dd348 <+600>: mov %r14,-0x188(%rbp)
0x00007ffff67dd34f <+607>: mov (%rax),%rax
0x00007ffff67dd352 <+610>: mov %rax,-0x98(%rbp)
0x00007ffff67dd359 <+617>: mov 0x160(%rax),%rdi
0x00007ffff67dd360 <+624>: callq 0x7ffff671d5f0
<GrowableArray<Metadata*>::append(Metadata* const&)>
>>> CRASH %r14 == 0x0
198 jmethodID to_jmethodID(methodHandle method) { return
method->jmethod_id(); }
0x00007ffff67dd365 <+629>: mov 0x8(%r14),%rax
Hope this helps
- Ioi
On 5/8/18 4:51 PM, serguei.spit...@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.spit...@oracle.com
<mailto:serguei.spit...@oracle.com> <serguei.spit...@oracle.com
<mailto:serguei.spit...@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
<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
