Relates :
|
|
Relates :
|
|
Relates :
|
I got a crash running JBB under the collector. On inspection of the crash log, I found that the code in forte.cpp which validates the Lmethod of an interpreter frame is not cautious enough. static inline bool forte_is_valid_method(methodOop method) { if (method == NULL || // The methodOop is extracted via an offset from the current // interpreter frame. With AsyncGetCallTrace() the interpreter // frame may still be under construction so we need to make // sure that we got an aligned oop before we try to use it. !Space::is_aligned(method) || !Universe::heap()->is_in_reserved((void*)method) || // See if GC became active after we entered AsyncGetCallTrace() // and before we try to use the methodOop. This routine is // used in validation of the top_frame so we don't have any // other data to flush if we bail due to GC here. // Yes, there is still a window after this check and before // we use methodOop below, but we can't lock out GC so that // has to be an acceptable risk. Universe::heap()->is_gc_active() || // klass() does not need vtable dispatch so check before is_perm() oop(method)->klass() != Universe::methodKlassObj() || !method->is_perm() || !method->is_method()) { return false; // doesn't look good } return true; // hopefully this is a method indeed } In the above method, the is_perm call must come before the klass check. If not, you can get a method pointing into the unmapped part of the heap's reserved area (e.g., a very high address just within bounds), and the instruction which loads the class will SEGV. This is what happened to me. (You should remove the comment about a vtable, which appears to be a thoughtless and useless optimization. Nobody cares which order the tests come in, since in most cases both tests are going to be run, since most frame collection attempts are successful.)
|