Skip to main content

Signal 4 in PhoneME Advanced

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
2 replies [Last post]
mtennant
Offline
Joined: 2011-01-28

Hi all,

We use PhoneME Advanced on a couple platforms with our Java/OSGi embedded
product, and recently we consistently hit a signal 4 (illegal instruction)
on one of those platforms. I am hoping the people on this list can help us
resolve the problem.

Unfortunately, I am not sure what component of our code is triggering the
bug in PhoneME. It typically takes a couple hours to happen for us, and our
application is fairly elaborate. It looks to be related to an Object.wait
call (we have a multi-threaded environment). I wish I could provide a small
program to recreate the error on demand, but as of now I cannot.

I do have a stacktrace for the error, and if someone can look at that
(below) and give me feedback on what type of call to Object.wait might
trigger the problem, I can look at our code and perhaps create a testcase
through some trial and error. I would need something to narrow my search,
though.

Again, this is happening for us on one platform but not others. That
platform is a "PCPlug", and the output of "uname -a" is:
Linux ubuntu 2.6.30.2 #1 PREEMPT Wed Oct 21 10:00:21 PHT 2009 armv5tel
GNU/Linux

We first found this problem with phoneme_advanced_mr2-dev-b47, but I tested
with the newer mr2-dev-b167 and the problem is still there. I am using a
compile line that looks like the following (the compile options are the
important part):
cd
$(PHONEME_BUILD_DIR)/$(PHONEME_ADVANCED_DIR)/cdc/build/$(PHONEME_ARCH);
TARGET_AR=$(CROSS_COMPILE)-ar TARGET_CCC=$(CROSS_COMPILE)-g++
TARGET_RANLIB=$(CROSS_COMPILE)-ranlib TARGET_CC=$(CROSS_COMPILE)-gcc $(MAKE)
-I$(PHONEME_BUILD_DIR)/$(PHONEME_ADVANCED_DIR)/cdc/build/$(PHONEME_ARCH)/
CVM_JIT=false CVM_JIT_USE_FP_HARDWARE=false J2ME_CLASSLIB=foundation
CVM_DEBUG_DUMPSTACK=true CVM_DEBUG=true
PROFILE_DIR=$(PHONEME_BUILD_DIR)/$(PHONEME_ADVANCED_DIR)/cdc

And finally, the stack trace:

(gdb) backtrace
#0 0x40030f90 in pthread_cond_wait@@GLIBC_2.4 () from /lib/libpthread.so.0
#1 0x00168a44 in CVMcondvarWait (c=0x484bbde8, m=0x484bbdd0, millis=0)
at ../../src/linux/javavm/runtime/sync_md.c:340
#2 0x00080c9c in CVMreentrantMutexWait (ee=0x397c18, rm=0x484bbdc8,
c=0x484bbde8, millis=0) at ../../src/share/javavm/runtime/sync.c:217
#3 0x00080efc in CVMsysMonitorWait (ee=0x397c18, mon=0x484bbdc8, millis=0)
at ../../src/share/javavm/runtime/sync.c:303
#4 0x0006d54c in CVMprivateWait (ee=0x397c18, indirectObj=0x3d9310,
millis=0, fast=1) at ../../src/share/javavm/runtime/objsync.c:1861
#5 0x0006da08 in CVMfastWait (ee=0x397c18, indirectObj=0x3d9310, millis=0)
at ../../src/share/javavm/runtime/objsync.c:1920
#6 0x000720c8 in CVMgcSafeObjectWait (ee=0x397c18, o=0x3d9310, millis=0)
at ../../src/share/javavm/runtime/objsync.c:3365
#7 0x000ece88 in Java_java_lang_Object_wait (env=0x397c44, obj=0x3d9310,
millis=0) at ../../src/share/javavm/runtime/jvm.c:1677
#8 0x0018fcd4 in args_done ()
at ../../src/arm/javavm/runtime/invokeNative_arm.S:234
Backtrace stopped: frame did not save the PC

Any help is much appreciated. If I can provide any more details, please
ask.
Matt Tennant

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Hinkmond Wong Guest
Offline
Joined: 2010-11-03

On 1/28/2011 3:56 PM, Matt Tennant wrote:
> Hi all,
>
> We use PhoneME Advanced on a couple platforms with our Java/OSGi
> embedded product, and recently we consistently hit a signal 4 (illegal
> instruction) on one of those platforms. I am hoping the people on
> this list can help us resolve the problem.
>
> Unfortunately, I am not sure what component of our code is triggering
> the bug in PhoneME. It typically takes a couple hours to happen for
> us, and our application is fairly elaborate. It looks to be related
> to an Object.wait call (we have a multi-threaded environment). I wish
> I could provide a small program to recreate the error on demand, but
> as of now I cannot.
>
> I do have a stacktrace for the error, and if someone can look at that
> (below) and give me feedback on what type of call to Object.wait might
> trigger the problem, I can look at our code and perhaps create a
> testcase through some trial and error. I would need something to
> narrow my search, though.
>
> Again, this is happening for us on one platform but not others. That
> platform is a "PCPlug", and the output of "uname -a" is:
> Linux ubuntu 2.6.30.2 #1 PREEMPT Wed Oct 21 10:00:21 PHT 2009 armv5tel
> GNU/Linux
>
> We first found this problem with phoneme_advanced_mr2-dev-b47, but I
> tested with the newer mr2-dev-b167 and the problem is still there. I
> am using a compile line that looks like the following (the compile
> options are the important part):
> cd
> $(PHONEME_BUILD_DIR)/$(PHONEME_ADVANCED_DIR)/cdc/build/$(PHONEME_ARCH); TARGET_AR=$(CROSS_COMPILE)-ar
> TARGET_CCC=$(CROSS_COMPILE)-g++ TARGET_RANLIB=$(CROSS_COMPILE)-ranlib
> TARGET_CC=$(CROSS_COMPILE)-gcc $(MAKE)
> -I$(PHONEME_BUILD_DIR)/$(PHONEME_ADVANCED_DIR)/cdc/build/$(PHONEME_ARCH)/
> CVM_JIT=false CVM_JIT_USE_FP_HARDWARE=false J2ME_CLASSLIB=foundation
> CVM_DEBUG_DUMPSTACK=true CVM_DEBUG=true
> PROFILE_DIR=$(PHONEME_BUILD_DIR)/$(PHONEME_ADVANCED_DIR)/cdc
>
> And finally, the stack trace:
> (gdb) backtrace
> #0 0x40030f90 inpthread_cond_wait@@GLIBC_2.4 () from /lib/libpthread.so.0
> #1 0x00168a44 in CVMcondvarWait (c=0x484bbde8, m=0x484bbdd0, millis=0)

Chris or Dean, do you have any hints for Matt in regard to this bug in
CVM he's seeing? Maybe there is some detailed info he can gather and
give you to help track down this error? (Matt contacted me that he
didn't see any response yet and I mentioned that it is probably because
there is not enough info in general yet on the error he's seeing)

Thanks,
Hinkmond

>
> at ../../src/linux/javavm/runtime/sync_md.c:340
> #2 0x00080c9c in CVMreentrantMutexWait (ee=0x397c18, rm=0x484bbdc8,
> c=0x484bbde8, millis=0) at ../../src/share/javavm/runtime/sync.c:217
> #3 0x00080efc in CVMsysMonitorWait (ee=0x397c18, mon=0x484bbdc8, millis=0)
>
> at ../../src/share/javavm/runtime/sync.c:303
> #4 0x0006d54c in CVMprivateWait (ee=0x397c18, indirectObj=0x3d9310,
> millis=0, fast=1) at ../../src/share/javavm/runtime/objsync.c:1861
> #5 0x0006da08 in CVMfastWait (ee=0x397c18, indirectObj=0x3d9310, millis=0)
>
> at ../../src/share/javavm/runtime/objsync.c:1920
> #6 0x000720c8 in CVMgcSafeObjectWait (ee=0x397c18, o=0x3d9310, millis=0)
> at ../../src/share/javavm/runtime/objsync.c:3365
> #7 0x000ece88 in Java_java_lang_Object_wait (env=0x397c44, obj=0x3d9310,
>
> millis=0) at ../../src/share/javavm/runtime/jvm.c:1677
> #8 0x0018fcd4 in args_done ()
> at ../../src/arm/javavm/runtime/invokeNative_arm.S:234
> Backtrace stopped: frame did not save the PC
>
> Any help is much appreciated. If I can provide any more details,
> please ask.
> Matt Tennant

davyp
Offline
Joined: 2007-01-03

You probably figured out that Signal 4 (SIGILL) is an illegal machine instruction. There are several reasons
why this may occur: broken hardware, memory corruption, a compiler that produced an instruction that the
CPU does not understand. Which compiler and version do you use?

The backtrace you provided seems to indicate the error occurred in pthread_cond_wait@@GLIBC_2.4,
so in theory it is possible that there is an issue with this library. But you would have to be sure that you
have the backtrace of all the threads and that the signal 4 did not occur in another thread.

FWIW: I have a recent build of the Foundation Profile for ARM GNUEABI on my website. Perhaps you can
check whether this build has the same issue.

http://davy.preuveneers.be/phoneme/?q=node/10#armgnueabi

Cheers,
Davy