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.sh...@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.sh...@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:
>> s...@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.sh...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Dec 3, 2009 at 9:01 AM, Nathan Beyer <ndbe...@apache.org> wrote:
>>>
>>>> On Wed, Dec 2, 2009 at 7:51 AM, Tianwei <tianwei.sh...@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.
