Skip to main content

Signal 11 on MIPS32 LE

2 replies [Last post]
Joined: 2007-07-05

Hi, all:
I use phoneme-advanced-mr1 and run on MIPS LE target board.
I got the siganl 11 after some assertion.

Assertion failed at line 401 in ../../src/portlibs/jit/risc/jit_risc.c: con->gcCheckPcsIndex == con->gcCheckPcsSize
Compiled Frame java.awt.Container.paint(Ljava/awt/Graphics;)V(Compiled Method)(
Java Frame org.havi.ui.HScene.paint(Ljava/awt/Graphics;)V(
Compiled Frame org.havi.ui.HScene.repaint(IIII)V(Compiled Method)(
Java Frame org.havi.ui.HVisible.repaint()V(

Here is the back trace in gdb.
(gdb) bt
#0 0x00498488 in CVMassertHook (
filename=0x694560 "../../src/portlibs/jit/risc/jit_risc.c", lineno=401,
expr=0x694780 "con->gcCheckPcsIndex == con->gcCheckPcsSize")
at ../../src/share/javavm/runtime/interpreter.c:3362
#1 0x00613ea8 in CVMJITcompileGenerateCode (con=0x7dffe150)
at ../../src/portlibs/jit/risc/jit_risc.c:401
#2 0x004ce2b4 in CVMJITcompileMethod (ee=0x104eb5e0, mb=0x10183774)
at ../../src/share/javavm/runtime/jit/jitcompile.c:492
#3 0x0064836c in CVMgcUnsafeExecuteJavaMethod (ee=0x104eb5e0, mb=0x10183774,
isStatic=0, isVirtual=0)
at ../../src/share/javavm/runtime/executejava_standard.c:3224
#4 0x0053ba64 in CVMjniInvoke (env=0x104eb60c, obj=0x1034a754,
methodID=0x100dc734, pushArguments=0x53a7b8 ,
args=0x7dfffc80, info=258, retValue=0x0)
at ../../src/share/javavm/runtime/jni_impl.c:2622
#5 0x0053f02c in CVMjniCallVoidMethod (env=0x104eb60c, obj=0x1034a754,
methodID=0x100dc734) at ../../src/share/javavm/runtime/jni_impl.c:2842
#6 0x00555a98 in start_func (arg=0x1035a680)
at ../../src/share/javavm/runtime/jvm.c:1870
#7 0x00618718 in start_func (a=0x104e5b40)
at ../../src/portlibs/posix/posix_threads_md.c:43
#8 0x2aaf2180 in pthread_start_thread ()

Could some one give me some suggestion? Does CVM crash in GC?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-10-16

Failed asserts always result in a signal 11. This is by design, is done so they don't go unnoticed. The one you are seeing is not a crash in GC, but is a problem detected while the JIT is compiling a method. Somewhere a miscalculation was made on the number of gc checkpoints the method should have. If we calculated too many, then the assert is harmless. It could be removed and this particular miscalculation would not cause any problems. If the calculation is too low, then most likely you would see a crash later on, even if the assert is removed. To see which it is, you can display the values being checked from GDB.

You should also see if this reproduces in MR2. It may be something that is already fixed, although I could not find a bug report that contained this assert in it.



Joined: 2007-07-05

Hi, Chris:
Thanks for reply. I comment out the assetion and the vm runs well.