sorry, miss something for the previous trace:
[trace] StartLoading class [Ljava/lang/StackTraceElement; with loader
0x450fc0
[trace] initializing class java/lang/System
[trace] initializing class java/lang/System STEP 2
[trace] StartLoading class java/lang/NoClassDefFoundError with loader
0x450fc0
[trace] initializing class java/lang/NoClassDefFoundError
[trace] initializing class java/lang/NoClassDefFoundError STEP 2
[trace] initializing class java/lang/NoClassDefFoundErrorSTEP 6
[trace] class java/lang/NoClassDefFoundError initialized
[trace] exn_raise_object(), propagating lazy & non-destructively
[trace] interpreter: 0x6f3608.<init>(Ljava/lang/String;)V
[trace] interpreter: 0x6f3440.<init>(Ljava/lang/String;)V
[trace] interpreter: 0x6f31b0.<init>(Ljava/lang/String;)V
[trace] interpreter: 0x6f2ec8.<init>(Ljava/lang/String;)V
[trace] interpreter: 0x468358.<init>()V
[trace] interpreter: 0x6f2ec8.fillInStackTrace()Ljava/lang/Throwable;
[trace] interpreter static native:
0x787048.getStackState()Ljava/lang/Object;
[trace] interpreter static native:
0x787048.getStackClasses(Ljava/lang/Object;)[Ljava/lang/Class;


Does that mean it has some problem with loading
"[Ljava/lang/StackTraceElement"?

Thanks.

Tianwei
On Sun, Dec 27, 2009 at 8:26 PM, Tianwei <tianwei.sheng@gmail.com> wrote:

> OK, when using  -Xtrace:harmonyvm, the tail of the trace looks like:
> trace] interpreter: 0x6f2740.toString()Ljava/lang/String;
> [trace] interpreter: 0x6f2740.toString()Ljava/lang/String;
> [trace] interpreter: 0x6f3498.<init>(Ljava/lang/String;)V
> [trace] interpreter: 0x6f32d0.<init>(Ljava/lang/String;)V
> [trace] interpreter: 0x6f3040.<init>(Ljava/lang/String;)V
> [trace] interpreter: 0x6f2d58.<init>(Ljava/lang/String;)V
> [trace] interpreter: 0x4682f8.<init>()V
> [trace] interpreter: 0x6f2d58.fillInStackTrace()Ljava/lang/Throwable;
> [trace] interpreter static native:
> 0x786ed8.getStackState()Ljava/lang/Object;
> [trace] interpreter static native:
> 0x786ed8.getStackClasses(Ljava/lang/Object;)[Ljava/lang/Class;
> java:
> /home/stw/harmony/harmony-nofetch/working_vm/vm/vmcore/src/exception/exceptions.cpp:574:
> exn_native_print_stack_trace: Assertion `hythread_is_suspend_enabled()'
> failed.
> Aborted
>
> Tianwei
>
> On Sun, Dec 27, 2009 at 7:59 PM, Tianwei <tianwei.sheng@gmail.com> wrote:
>
>> Hi, all,
>>    I met a difficult problem again. Now based on Charles's patch, I can go
>> further on my MIPS machine. But I met the following error when using
>> interpreter:
>> stw@RAYS-b0f748fa:~/test$
>> /home/stw/harmony/harmony-nofetch/working_vm/build/linux_mips32_gcc_debug/deploy/jdk/jre/bin/java
>> -Xint -Xtrace:vm.core  HelloWorldApp
>>
>> checking table sizes: 96/96
>>
>> checking table sizes: 96/96
>>
>> [trace] Initializing VM
>>
>> [trace] analyzing em dll libem.so
>>
>> [trace] analyzing gc.dll libgc_gen_uncomp.so
>>
>> [trace] bootstrapping initial java classes
>>
>> [trace] bootstrapping initial java classes complete
>>
>> [trace] get class methods : java/lang/Thread
>>
>> [trace] Failed to initialize new thread object, exception =
>> java/lang/ExceptionInInitializerError
>>
>> java/lang/ExceptionInInitializerError : (null)
>> java:
>> /home/stw/harmony/harmony-nofetch/working_vm/vm/vmcore/src/exception/exceptions.cpp:574:
>> exn_native_print_stack_trace: Assertion `hythread_is_suspend_enabled()'
>> failed.
>> Aborted
>>
>>
>> I debug the code with gdb a lot(compared with X86_64 version), but was
>> lost inside the large code base. I also were reading Harmony's document and
>> try to understand the whole framework.  But it's really very difficult ;-(
>> I want to know if someone can give me some suggestions for such bugs, also
>> are there any useful debugging tips(trace, logging facilities) for my
>> porting work?
>>
>> more information for the exception, I use gdb to trace the bug for the
>> source code is:
>>   void
>>   interpreter(StackFrame &frame) {
>>       while (true) {
>>           ip0 = *frame.ip;
>>          switch(ip0) {
>>            ...............
>>              case OPCODE_INVOKESTATIC:
>>                                  Opcode_INVOKESTATIC(frame);
>>                                   frame.exc =
>> get_current_thread_exception();
>>                                   if (frame.exc != 0) goto got_exception;
>>                                   frame.ip += 3;
>>                                   break;
>>
>>       }
>>    got_exception:
>>             ................
>> }
>>
>> but hard to further locate the root cause.
>>
>> Any suggestions?
>>
>> Thanks very much
>>
>> Tianwei
>> On Thu, Dec 3, 2009 at 10:31 AM, Tianwei <tianwei.sheng@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Dec 3, 2009 at 9:01 AM, Nathan Beyer <ndbeyer@apache.org> wrote:
>>>
>>>> On Wed, Dec 2, 2009 at 7:51 AM, Tianwei <tianwei.sheng@gmail.com>
>>>> wrote:
>>>> > Hi, all,
>>>> >  I got some progress for applying  Charles's patch sent two weeks ago.
>>>> > However, I also met some hard issues which I want to ask for
>>>> suggestions.
>>>> > I am totally new for harmony development, so I want to hear your
>>>> valuable
>>>> > suggestions for my work.
>>>> > My experiments step are:
>>>> > 1. apply the patch on X86_64 (ubuntu 9.04)
>>>> >    at this step, I also checkout a clean trunk, maintain two
>>>> directories
>>>> >    trunk and trunk-mips(patched by MIPS patch)
>>>> >  after fixing some problems, I compare the testing result(ant test)
>>>> for
>>>> > these two versions, the result is same where I assume the modified
>>>> patch
>>>> > work on X86(no regression).
>>>> >  for this step, the main problems of original patch are:
>>>> >   a. there is some problem when using "unless", such as:
>>>> >      --- working_vm/make/vm/interpreter.xml  (revision 833674)
>>>> > +++ working_vm/make/vm/interpreter.xml  (working copy)
>>>> > @@ -71,6 +71,7 @@
>>>> >                 <exclude name="interp_native_ia32.cpp"
>>>> unless="is.x86"/>
>>>> >                 <exclude name="interp_native_ipf.cpp"
>>>> unless="is.ia64"/>
>>>> >                 <exclude name="interp_native_em64t.cpp"
>>>> > unless="is.x86_64"/>
>>>> > +                <exclude name="interp_native_mips.cpp"
>>>> unless="is.mips"/>
>>>> >             </fileset>
>>>>
>>>> Perhaps this is obvious, but is the 'is.mips' property being setup?
>>>> When you run 'ant echo' in the 'working_classlib' folder do you see a
>>>> 'is.mips' line in with the other platforms, like this.
>>>>
>>>>     [echo]   is.windows = ${is.windows}
>>>>     [echo]   is.unix = true
>>>>     [echo]   is.linux = true
>>>>     [echo]   is.freebsd = ${is.freebsd}
>>>>     [echo]   is.macosx = ${is.macosx}
>>>>     [echo]   is.aix = ${is.aix}
>>>>     [echo]   is.zos = ${is.zos}
>>>>     [echo]   is.32bit = true
>>>>     [echo]   is.64bit = ${is.64bit}
>>>>     [echo]   is.x86 = true
>>>>     [echo]   is.x86_64 = ${is.x86_64}
>>>>     [echo]   is.ia64 = ${is.ia64}
>>>>     [echo]   is.ppc32 = ${is.ppc32}
>>>>     [echo]   is.ppc64 = ${is.ppc64}
>>>>     [echo]   is.s390 = ${is.s390}
>>>>     [echo]   is.s390x = ${is.s390x}
>>>>
>>>>
>>>> Ah, I did not see the is_mips32, but I added the line in
>>> common_resources/make/platform.xml where I thought it would set is_mips32
>>> according to $os_arch.  I think this should be set because I used this to
>>> add the defineset, such as -D_MIPS_.
>>>
>>> Tianwei
>>>
>>>> >  b. the original patch has several problems under the
>>>> >  working_vm/vm/jitrino/src/jet directory, so I do not use the diff for
>>>> that
>>>> > directory
>>>> >
>>>> > 2. apply the patch on my MIPS machine
>>>> >    at this step, I mainly fix a lot of ant make system error since the
>>>> > original patch did not include the makefile patch as Charles said.
>>>> >    typical fixes mainly include:
>>>> >     a. copy the linux_ppc32.mk to linux_mips32.mk
>>>> >     b. comment out the ABORT where I can not find the definition
>>>> >     c.
>>>> > /home/stw/harmony/harmony-nofetch/common_resources/make/platform.xml
>>>> > +    <condition property="is.mips32">
>>>> >
>>>> > +        <or>
>>>> > +            <equals arg1="${os.arch}" arg2="mips32" />
>>>> > +            <equals arg1="${os.arch}" arg2="mips" />
>>>> > +        </or>
>>>> > +    </condition>
>>>> > +    <condition property="is.mips64">
>>>> > +        <equals arg1="${os.arch}" arg2="mips64" />
>>>> > +    </condition>
>>>> >   d: manually build the icu-3.4 library since no prebuilt library
>>>> package
>>>> > available
>>>> >   e: vmcore.xml
>>>> > +                               <include
>>>> > name="vmcore/src/util/mips/base_natives" if="is.mips32"/>
>>>> > +                               <include name="port/src/encoder/mips"
>>>> > if="is.mips32"/>
>>>> > +                               <include
>>>> name="vmcore/src/lil/mips/include"
>>>> > if="is.mips32"/>
>>>> > ...................others minor fixes...........
>>>> > 3. after step 2, I finally can build the whole hdk(working_classlib,
>>>> > working_vm, working_jdktools), then I tried to run the
>>>> HelloWorld.java,
>>>> > however, I met segmentation fault at the very begging of the launcher.
>>>> > I debug this problem, and the following is my finding now:
>>>> >   a. the gdb backtrace is:
>>>> > (gdb) bt
>>>> > #0  0x2aaf5164 in apr_initialize () at misc/unix/start.c:46
>>>> > #1  0x2aaebecc in hythread_lib_create (lib=0x2ab299b0) at
>>>> > /home/stw/harmony/harmony-nofetch/working_vm/vm/thread/src/thread_i\
>>>> > nit.c:176
>>>> > #2  0x2aaebe54 in hythread_library_init () at
>>>> >
>>>> /home/stw/harmony/harmony-nofetch/working_vm/vm/thread/src/thread_init.c:70
>>>> >    b. when I use disass under gdb, I found that one instruction
>>>> > in apr_initialize caused the problem:
>>>> >        0x2aaf5160 <apr_initialize+28>: lui     v0,0x5
>>>> >        0x2aaf5164 <apr_initialize+32>: lw      v1,-9760(v0)
>>>> >    c. then I suspect its apr's problem, so I rebuilt the apr with -O0,
>>>> then
>>>> > first verify using the test/testall, all tests passed
>>>> >        I even execute the test/sockperf alone, it also pass, note that
>>>> > sockperf call apr_initialize in its main function, but no segmentation
>>>> > fault,
>>>> >       so I assume apr has no problems.
>>>> >    d. then I rebuilt the hdk, but the segmentation problem still
>>>> exists.
>>>> >    e. finally I suspect that there may be some problem with gp issues,
>>>> but
>>>> > I have no clues. When checking how the launcher is built, I am
>>>> confused with
>>>> > libhythr.so, it seems that the launcher is first built under
>>>> > working_classlib, link with libhythr.so under
>>>> > working_classlib/modules/portlib/src/main/native/thread/, then after
>>>> the
>>>> > launcher is copied into working_vm, it will be linked with libhythr.so
>>>> > under working_vm/vm/thread/src/, is that right?
>>>> >       but I still can not figure out the root cause, can anyone give
>>>> me
>>>> > some suggestions for this hard issue, or someone also experienced
>>>> similar
>>>> > issues before?
>>>> >
>>>> >
>>>> > the Summary:
>>>> >   1. no regression on X86_64 for the MIPS patch
>>>> >   2. buildable on MIPS for that patch
>>>> >   3. running time error(segmentation fault) at the very begging of the
>>>> > launcher on MIPS
>>>> >
>>>> >
>>>> > Thanks.
>>>> >
>>>> > Tianwei
>>>> > --
>>>> > Sheng, Tianwei
>>>> > Inst. of High Performance Computing
>>>> > Dept. of Computer Sci. & Tech.
>>>> > Tsinghua Univ.
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> Sheng, Tianwei
>>> Inst. of High Performance Computing
>>> Dept. of Computer Sci. & Tech.
>>> Tsinghua Univ.
>>>
>>
>>
>>
>> --
>> Sheng, Tianwei
>> Inst. of High Performance Computing
>> Dept. of Computer Sci. & Tech.
>> Tsinghua Univ.
>>
>
>
>
> --
> Sheng, Tianwei
> Inst. of High Performance Computing
> Dept. of Computer Sci. & Tech.
> Tsinghua Univ.
>



-- 
Sheng, Tianwei
Inst. of High Performance Computing
Dept. of Computer Sci. & Tech.
Tsinghua Univ.