1.4.2-internal-debug fails with assert(m->is_perm(),"bad methodOop in interpreter frame")

Failure in 1.4.2_16 fastdebug with error

   assert(m->is_perm(),"bad methodOop in interpreter frame")

using the following options:

-Xms1024m -Xmx1024m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:MaxPermSize=256m -XX:+VerifyBeforeGC -XX:+VerifyAfterGC -Xloggc:gc.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseParNewGC -XX:+UseConcMarkSweepGC

# Internal Error (/net/jlab113/export3/jpse/pb131437/1.4.2/hotspot/src/share/vm/runtime/frame.cpp, 265 [ Patched ]), pid=631, tid=4
#
# Java VM: Java HotSpot(TM) Server VM (1.4.2-internal-debug mixed mode)
#
# Error: assert(m->is_perm(),"bad methodOop in interpreter frame")

The stack is

----------------- lwp# 6 / thread# 6 --------------------
 ff2c1adc _lwp_kill (6, 0, ff2ee450, ff2a4d94, ffffffff, 6) + 8
 ff240218 abort (a84ff350, 1, fe4c6ad4, aa1a0, ff2ed2d8, 0) + 110
 fe4bb030 void os::abort(int) (1, fede6004, 1, 80808080, ff0000, 80808080) + 168
 fe6c0824 void VMError::report_and_die() (fefbb5cf, fefbb5de, fefbb5ee, 3b400, 3b6b4, ff0d5ea0) + a90
 fe000500 void report_assertion_failure(const char*,int,const char*) (fe97a549, 109, fe97a599, f8c0f9d4, faac20, fe05c428) + 44
 fe05c498 methodOopDesc*frame::interpreter_frame_method()const (a84ff6fc, f8c04fc0, 134ca0, f8c0f9d4, faac20, fe05d9c8) + 90
 fe05da38 void frame::oops_interpreted_do(OopClosure*,const RegisterMap*) (a84ff710, ff0bab20, a84ff710, f8c0f9d4, faac20, fe05f72c) + 90
 fe05f744 void frame::oops_do(OopClosure*,RegisterMap*) (a84ff6fc, ff0bab20, a84ff710, ff0a05ac, ff0a4f1c, fe46c524) + 34
 fe660f84 void JavaThread::oops_do(OopClosure*) (3d568, ff0bab20, 8, a84ffa14, 0, a84ff1f4) + 1f0
 fe668e58 void Threads::verify() (34d58, fef84385, 10, a84ffab4, 0, a84ff294) + 4c
 fe694604 void Universe::verify(int,int) (1, 0, 1, 102e974, 0, 0) + 27c
 fe079aac void GenCollectedHeap::do_collection(int,int,unsigned,int,int,int,int&) (1, cd718, 0, ff0e99fc, 0, 0) + a00
 fe07b968 void GenCollectedHeap::do_full_collection(int,int,int&) (cd6d0, 0, 1, 9937f830, fa4b28, ffffff8c) + 5c
 fe6d69e4 void VM_GenCollectFull::doit() (9937f814, fefe2687, ff000000, ff000000, b553f0, fe46c524) + dc
 fe6d6154 void VM_Operation::evaluate() (9937f814, 46, 37628, ff0e4fb0, ff0e7d4c, fe5b3d2c) + 188
 fe6d4218 void VMThread::evaluate_operation(VM_Operation*) (189eb8, 9937f814, 3a004, 935a58, fe6d4bc8, 3b990) + 13c
 fe6d4dec void VMThread::loop() (189eb8, 40, 37000, 3715c, 39000, 37800) + a2c
 fe6d3e90 void VMThread::run() (189eb8, 0, 40, 0, 40, 1) + f4
 fe4b90e0 java_start (189eb8, a8500000, 0, 0, fe4b8f50, 1) + 190
 ff2c08e8 _lwp_start (0, 0, 0, 0, 0, 0)


The standard jvm (without GC verification options) is continuosly crashing in ParRootScanWithoutBarrierClosure::do_oop with a similar stack to the already fixed 6322757 (1.4.2_12), but without the call to InterpreterOopMap::iterate_oop