Skip to main content

phoneME Advanced MR1: cvm failed with "ABRT" (SOS)

6 replies [Last post]
neozhc
Offline
Joined: 2010-06-09

I had been ported phoneME Advanced MR1 to an ARMv5TE platform and it works OK, now I'm working on porting it to another ARMv5TE platform with the same CPU as previous platform. I have not change the building scripts(please see another thread I posted: http://forums.java.net/jive/thread.jspa?threadID=150291&tstart=15) and the building procedure is OK, but it just can't work when running Java test applications with GUI.

I enabled the DEBUG feature, the personal.DemoFrame and basis.DemoFrame failed with "ABRT":
/opt/phoneME # ./bin/cvm -cp democlasses.jar personal.DemoFrame
CVM Configuration:
Java stack chunk size (stackChunkSize): 2048
Java stack minimum size (stackMinSize): 3072
Java stack maximum size (stackMaxSize): 131072
GC[SS]: Initialized semi-space gen for generational GC
Size of *each* semispace in bytes=1048576
Limits of generation = [0x401a0200,0x403a0200)
First semispace = [0x401a0200,0x402a0200)
Second semispace = [0x402a0200,0x403a0200)
GC[MC]: Initialized mark-compact gen for generational GC
Size of the space in bytes=4194304
Limits of generation = [0x403a0200,0x407a0200)
GC[generational]: Auxiliary data structures
heapBaseMemoryArea=[0x401a0008,0x407a0208)
cardTable=[0x46d1c0,0x4701c0)
objectHeaderTable=[0x4701c8,0x4731c8)
summaryTable=[0x4731d0,0x47f1d0)
JIT Configuration:
Interpreter transition cost (icost): 20
Mixed transition cost (mcost): 50
Backwards branch cost (bcost): 4
Compilation threshold (climit): 20000
When to compile (compile): policy
What to inline (inline): virtual+nonvirtual+vhints+ihints
Max Inlining Depth (maxInliningDepth): 12
Max Inlining Code Length (maxInliningCodeLength): 68
Min Inlining Code Length (minInliningCodeLength): 16
Policy Triggered Decompilations (policyTriggeredDecompilations): true
Max Working Memory Size (maxWorkingMemorySize): 563200
Max Compiled Method Size (maxCompiledMethodSize): 65535
Code Cache Size (codeCacheSize): 524288
Upper Code Cache Threshold (upperCodeCacheThreshold): 95%
Lower Code Cache Threshold (lowerCodeCacheThreshold): 90%
Pass Phi values in registers (XregisterPhis): true
Pass locals in registers between blocks (XregisterLocals): true
Compiling Causes Class Loading (XcompilingCausesClassLoading): false
Trace (trace): none
ABRT

The Java test applications without GUI work OK, such as cdc.HelloWorld:
/opt/phoneME # ./bin/cvm -cp democlasses.jar cdc.HelloWorld
CVM Configuration:
Java stack chunk size (stackChunkSize): 2048
Java stack minimum size (stackMinSize): 3072
Java stack maximum size (stackMaxSize): 131072
GC[SS]: Initialized semi-space gen for generational GC
Size of *each* semispace in bytes=1048576
Limits of generation = [0x401a0200,0x403a0200)
First semispace = [0x401a0200,0x402a0200)
Second semispace = [0x402a0200,0x403a0200)
GC[MC]: Initialized mark-compact gen for generational GC
Size of the space in bytes=4194304
Limits of generation = [0x403a0200,0x407a0200)
GC[generational]: Auxiliary data structures
heapBaseMemoryArea=[0x401a0008,0x407a0208)
cardTable=[0x46d1b8,0x4701b8)
objectHeaderTable=[0x4701c0,0x4731c0)
summaryTable=[0x4731c8,0x47f1c8)
JIT Configuration:
Interpreter transition cost (icost): 20
Mixed transition cost (mcost): 50
Backwards branch cost (bcost): 4
Compilation threshold (climit): 20000
When to compile (compile): policy
What to inline (inline): virtual+nonvirtual+vhints+ihints
Max Inlining Depth (maxInliningDepth): 12
Max Inlining Code Length (maxInliningCodeLength): 68
Min Inlining Code Length (minInliningCodeLength): 16
Policy Triggered Decompilations (policyTriggeredDecompilations): true
Max Working Memory Size (maxWorkingMemorySize): 563200
Max Compiled Method Size (maxCompiledMethodSize): 65535
Code Cache Size (codeCacheSize): 524288
Upper Code Cache Threshold (upperCodeCacheThreshold): 95%
Lower Code Cache Threshold (lowerCodeCacheThreshold): 90%
Pass Phi values in registers (XregisterPhis): true
Pass locals in registers between blocks (XregisterLocals): true
Compiling Causes Class Loading (XcompilingCausesClassLoading): false
Trace (trace): none
Hello world.

It's strange that when I disabled the DEBUG feature, not only DemoFrame, but also the HelloWorld will not work too.

By the way, the Qtopia-2.2.0 works OK.

Does anyone know how to make it work? I'm rather confused and need your help.

Thanks a lot.

Message was edited by: neozhc

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
neozhc
Offline
Joined: 2010-06-09

The trunk is OK!
Thank you, cjplummer.

cjplummer
Offline
Joined: 2006-10-16

My guess is that although the processor is the same, you have different ABI requirements on the new platform. Possibly you are not even using the right toolchain for it. For your cdc builds, try adding the following to the GNUmakefile:

CVM_DEFINES += -DAAPCS

If you already see that there, then try removing it.

I also suggest try building from the trunk rather than MR1, which is 4 years old. I can't even recall all the ABI related issues we've dealt with in that time. You should also be doing this if you are doing benchmarking, since the trunk should be faster than MR1.

neozhc
Offline
Joined: 2010-06-09

Adding or removing "CVM_DEFINES += -DAAPCS" does not help.

Possibly something is wrong with the toolchain, but it's specially optimized for the CPU of my platform and it's well tested.

I'll try a common version of toolchain and try building a latest version from the trunk rather than MR1.

Thanks a lot.

cjplummer
Offline
Joined: 2006-10-16

In many ways, getting the ABI right is more important than generating code specifically for your processor.

If you use the trunk, start with a CVM_DEBUG=true build. Then if you get the AAPCS setting wrong, you'll get an assert (only with the trunk, not MR1). Use USE_AAPCS=true (or false) to control the AAPCS setting (with the trunk only, not MR1).

neozhc
Offline
Joined: 2010-06-09

OK, thank you very much, I'm trying.

neozhc
Offline
Joined: 2010-06-09

By the way, I'm preparing a paper comparing the performance between common embedded JVMs running on ARM platform, including phoneME/Dalvik/JamVM/SableVM/Kaffe, any information related will be helpful.