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.
