Re: SIGSEGV issue
> > > >No, just trunk, sorry. Jakub jelinek is going to do a backport of ARM > >EABI gcc but he hasn't doine it yet AFAIAA. > > >You don't really need stack traces to debug this: you can used gdb > >instead. But I wouldn't consider using such an old gcj on ARM. Hi Andrew, It seems you were talking about these trunks ( http://gcc.gnu.org/svn/gcc/trunk/), weren't you? Can I exploit them for a compilation with crosstool? Also, I have seen that solving my issue just consists in applying a patch on backtrace.h, correct? Can I apply this patch in any official gcc 4.2.x? Thanks, David Sayada.
RE: SIGSEGV issue
>No, just trunk, sorry. Jakub jelinek is going to do a backport of ARM >EABI gcc but he hasn't doine it yet AFAIAA. >You don't really need stack traces to debug this: you can used gdb >instead. But I wouldn't consider using such an old gcj on ARM. >Andrew. The complete stack trace (I missed some stages in the previous email). I am wondering if I am building the application the right way. #0 0x40024250 in _Unwind_GetIPInfo () from /nfsroot/lib/libgcc_s.so.1 #1 0x003332d0 in _Jv_StackTrace::UnwindTraceFn (context=0xbef46ce8, state_ptr=) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/stacktrace.cc:137 #2 0x400247b8 in _Unwind_Backtrace () from /nfsroot/lib/libgcc_s.so.1 #3 0x00333204 in _Jv_StackTrace::GetStackTrace () at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/stacktrace.cc:170 #4 0x00339d7c in java::lang::VMThrowable::fillInStackTrace () at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/java/lang/natVMThrowable.cc:33 #5 0x0024d10c in java.lang.Throwable.fillInStackTrace()java.lang.Throwable (this=0xbef46ce8) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/classpath/java/lang/Throwable.java:498 #6 0x0024cb58 in java.lang.Throwable.Throwable(java.lang.String) (this=0x40208280, message=0x402792e8) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/classpath/java/lang/Throwable.java:159 #7 0x00237ef0 in java.lang.Exception.Exception(java.lang.String) (this=0xbef46ce8, s=0xbef46ccc) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/classpath/java/lang/Exception.java:77 #8 0x00235c74 in java.lang.ClassNotFoundException.ClassNotFoundException(java.lang.String) (this=0xbef46ce8, s=0xbef46ccc) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/classpath/java/lang/ClassNotFoundException.java:83 #9 0x00274bd0 in java.net.URLClassLoader.findClass(java.lang.String)java.lang.Class (this=0x401f10e0, className=0x4027fe70) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/java/net/URLClassLoader.java:1080 #10 0x001a0f50 in gnu.gcj.runtime.BootClassLoader.bootLoadClass(java.lang.String)java.lang.Cla ss (this=0xbef46ce8, name=0x4027fe70) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/gnu/gcj/runtime/BootClassLoader.java:55 #11 0x00187acc in java::lang::VMClassLoader::loadClass (name=0x4027fe70, resolve=0 '\0') at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/java/lang/natVMClassLoader.cc:208 #12 0x00182320 in _Jv_FindClass (name=0x40209d20, loader=0x0) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/java/lang/natClassLoader.cc:416 #13 0x001668a8 in _Jv_FindClassFromSignature (sig=0x77bfba ";", loader=0x0, endp=0x0) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/prims.cc:882 #14 0x00166938 in _Jv_FindClassFromSignatureNoException (sig=0x77bfa8 "[Ljava.lang.String;", loader=0x0, endp=0x0) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/prims.cc:916 #15 0x0017b584 in _Jv_Linker::resolve_pool_entry (klass=0x915e54, index=157, lazy=true) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/link.cc:301 #16 0x0017bbe0 in _Jv_Linker::ensure_class_linked (klass=0xbef46ccc) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/link.cc:1666 #17 0x0017be6c in _Jv_Linker::wait_for_state (klass=0x915e54, state=9) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/link.cc:1987 #18 0x0018177c in java::lang::Class::initializeClass (this=0xbef46ce8) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/java/lang/natClass.cc:695#19 0x00181850 in java::lang::Class::initializeClass (this=0x90eaf0) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/java/lang/Class.h:651 #20 0x001a6584 in gnu.java.lang.MainThread.()void () at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/gnu/java/lang/MainThread.java:62 #21 0x00181880 in java::lang::Class::initializeClass (this=0x90db50) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/java/lang/natClass.cc:750#22 0x0016632c in _Jv_AllocObjectNoFinalizer (klass=0x90db50) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/java/lang/
RE: SIGSEGV issue
>No, just trunk, sorry. Jakub jelinek is going to do a backport of ARM >EABI gcc but he hasn't doine it yet AFAIAA. >You don't really need stack traces to debug this: you can used gdb >instead. But I wouldn't consider using such an old gcj on ARM. >Andrew. The complete stack trace: #0 0x40024250 in _Unwind_GetIPInfo () from /nfsroot/lib/libgcc_s.so.1 #1 0x003332d0 in _Jv_StackTrace::UnwindTraceFn (context=0xbef46ce8, state_ptr=) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/stacktrace.cc:137 #2 0x400247b8 in _Unwind_Backtrace () from /nfsroot/lib/libgcc_s.so.1 #3 0x00333204 in _Jv_StackTrace::GetStackTrace () at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/stacktrace.cc:170 #4 0x00339d7c in java::lang::VMThrowable::fillInStackTrace () at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/java/lang/natVMThrowable.cc:33 #5 0x0024d10c in java.lang.Throwable.fillInStackTrace()java.lang.Throwable (this=0xbef46ce8) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/classpath/java/lang/Throwable.java:498 #6 0x0024cb58 in java.lang.Throwable.Throwable(java.lang.String) (this=0x40208280, message=0x402792e8) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/classpath/java/lang/Throwable.java:159 #7 0x00237ef0 in java.lang.Exception.Exception(java.lang.String) (this=0xbef46ce8, s=0xbef46ccc) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/classpath/java/lang/Exception.java:77 #8 0x00235c74 in java.lang.ClassNotFoundException.ClassNotFoundException(java.lang.String) (this=0xbef46ce8, s=0xbef46ccc) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/classpath/java/lang/ClassNotFoundException.java:83 #9 0x00274bd0 in java.net.URLClassLoader.findClass(java.lang.String)java.lang.Class (this=0x401f10e0, className=0x4027fe70) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/java/net/URLClassLoader.java:1080 #10 0x001a0f50 in gnu.gcj.runtime.BootClassLoader.bootLoadClass(java.lang.String)java.lang.Cla ss (this=0xbef46ce8, name=0x4027fe70) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/gnu/gcj/runtime/BootClassLoader.java:55 #11 0x00187acc in java::lang::VMClassLoader::loadClass (name=0x4027fe70, resolve=0 '\0') at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/java/lang/natVMClassLoader.cc:208 #12 0x00182320 in _Jv_FindClass (name=0x40209d20, loader=0x0) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/java/lang/natClassLoader.cc:416 #13 0x001668a8 in _Jv_FindClassFromSignature (sig=0x77bfba ";", loader=0x0, endp=0x0) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/prims.cc:882 #14 0x00166938 in _Jv_FindClassFromSignatureNoException (sig=0x77bfa8 "[Ljava.lang.String;", loader=0x0, endp=0x0) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.2.1-glibc-2.3.2/g cc-4.2.1/libjava/prims.cc:916
RE: SIGSEGV issue
>No, just trunk, sorry. Jakub jelinek is going to do a backport of ARM >EABI gcc but he hasn't doine it yet AFAIAA. >You don't really need stack traces to debug this: you can used gdb >instead. But I wouldn't consider using such an old gcj on ARM. >Andrew. Hi Andrew, I am now working with gcj 4.2.1 and I am getting the following SIGSEGV when my application starts, any idea? 0x40024250 in _Unwind_GetIPInfo () from /nfsroot/lib/libgcc_s.so.1 Thanks, David Sayada.
RE: SIGSEGV issue
> Upgrade gcc. They're known to work on gcc trunk, EABI, nowhere else. >Andrew. Will the latest gcc 4.1 fit my needs? Should I compile it with these options you gave me to support EABI? arm*-linux* ) slow_pthread_self=no can_unwind_signal=no CHECKREFSPEC=-fcheck-references DIVIDESPEC=-fuse-divide-subroutine ;; If not, can I please ask you to provide them to me? Many Thanks, David Sayada.
RE: SIGSEGV issue
>There's nothing I can see that should cause any trouble, but I suppose >the problem is that becasue stack traces on your version of gcj aren't >working you have no way to know where the problem is? Yes, correct. Is there a way to make them work? Thanks, David Sayada.
RE: SIGSEGV issue
David Sayada writes:
> For the moment I don't know. But can that be caused by an exception
> I am not catching between try and catch?
It's possible, but I'd have to debug it to know for sure.
Please stop top-posting.
Andrew.
Hi Andrew,
I hope I am not top posting now :-)
I think I have identified what can be the source of the problem. Please look
at the following scheme:
This is the infinite loop of one my threads:
while (true)
{
try
{
selectEventLoop();
}
catch (Exception e)
{
Logger.logPrintln( e );
}
} // of select loop
And this is the way the selectEventLoop is implemented:
void selectEventLoop() throws Exception
{
int nNumSelected = 0;
while ( nNumSelected == 0 )
{
signalSendChannels();
//Logger.logPrintln( "X Before select" );
nNumSelected = m_selector.select();
//Logger.logPrintln( "X After select" );
}
Set readyKeys = m_selector.selectedKeys();
Iterator iterator = readyKeys.iterator();
while (iterator.hasNext())
{
SelectionKey key = (SelectionKey) iterator.next();
iterator.remove();
try
{
...
}
catch (IOException ex)
{
Logger.logPrintln( ex );
closeChannel( key );
}
} // of selected keys iterator
}
May the parts of this function which are not under try and catch be
problematic? Should the exception thrown in this area not be caught by the
try and catch of the upper layer inside the infinite loop?
Best Regards,
David Sayada.
RE: SIGSEGV issue
Hi Andrew, For the moment I don't know. But can that be caused by an exception I am not catching between try and catch? Best Regards, David Sayada. -Original Message- From: Andrew Haley [mailto:[EMAIL PROTECTED] Sent: Monday, September 10, 2007 10:51 AM To: David Sayada Cc: classpath@gnu.org; 'Amnon David' Subject: RE: SIGSEGV issue David Sayada writes: > Having compiled gcj 4.1.2 with the options you quoted below, the application > no longer crashes with SEGV but I am receiving a lot of > java.lang.NullPointerException. > > I have tried to understand the conclusion of this thread > (http://gcc.gnu.org/ml/java/2001-04/msg00400.html) which deals with that > issue, but without success. Forget that patch. It was never applied. > Is this a natural behaviour? Or should there be a way to avoid them? Where do they occur? Please be as specific as you can. Andrew.
RE: SIGSEGV issue
Hi Andrew, Having compiled gcj 4.1.2 with the options you quoted below, the application no longer crashes with SEGV but I am receiving a lot of java.lang.NullPointerException. I have tried to understand the conclusion of this thread (http://gcc.gnu.org/ml/java/2001-04/msg00400.html) which deals with that issue, but without success. Is this a natural behaviour? Or should there be a way to avoid them? Best Regards David Sayada. -Original Message- From: Andrew Haley [mailto:[EMAIL PROTECTED] Sent: Thursday, September 06, 2007 12:49 PM To: David Sayada Cc: classpath@gnu.org; 'Amnon David' Subject: RE: SIGSEGV issue David Sayada writes: > Hi Andrew, > > Opening your link, I have noticed that the fcheck-references is defined for > arm-elf CPU. Also the arm-elf family is compatible with the processor I am > working with (PXA270). Then I will build a new toolchain for arm-elf based > on gcc 4.1.2 and make new tests. This top-posting is very confusing. Please stop. This is what matters: arm*-linux* ) slow_pthread_self=no can_unwind_signal=no CHECKREFSPEC=-fcheck-references DIVIDESPEC=-fuse-divide-subroutine ;; > > What do you think? It might work. Andrew. > > Best Regards, > David Sayada. > > -Original Message- > From: Andrew Haley [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 06, 2007 12:21 PM > To: David Sayada > Cc: classpath@gnu.org; 'Amnon David' > Subject: RE: SIGSEGV issue > > David Sayada writes: > > > > Reading specs from > > > /opt/crosstool/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux-gnu/bin/../lib/gcc/ar > > > m-unknown-linux-gnu/4.1.2/../../../../arm-unknown-linux-gnu/lib/libgcj.spec > > rename spec lib to liborig > > Target: arm-unknown-linux-gnu > > Configured with: > > > /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.1.2-glibc-2.3.2/g > > cc-4.1.2/configure --target=arm-unknown-linux-gnu > > --host=i686-host_pc-linux-gnu > > --prefix=/opt/crosstool2/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux-gnu > > > --with-headers=/opt/crosstool2/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux-gnu/a > > rm-unknown-linux-gnu/include > > > --with-local-prefix=/opt/crosstool2/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux- > > gnu/arm-unknown-linux-gnu --disable-nls --enable-threads=posix > > --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++,java > > --enable-shared --enable-c99 --enable-long-long > > Thread model: posix > > gcc version 4.1.2 > > > > The cross toolchain has been compiled with crosstool 0.43 from Dan Kegel. > > OK, it looks like the toolchain is totally misconfigured. My guess is > that this version of gcj on ARM doesn't work at all. > > You need -fcheck-references in that spec file, and the whole library > needs to be compiled with it. I have no idea whether gcj 4.1.2 ever > worked on ARM; I'm beginning to think not. > > Have a good look at > > http://gcc.gnu.org/svn/gcc/trunk/libjava/configure.host > > and make sure that the arm*-linux* sections are correct. > > This will help, but I suspect that gcj 4.1.2 will never work properly > on ARM. You need something much more recent. > > Andrew. > > > > > > # > # This spec file is read by gcj when linking. > # It is used to specify the standard libraries we need in order > # to link with libgcj. > # > %rename lib liborig > *lib: -lgcj -lm -lpthread-ldl %(libgcc) %(liborig) > > *jc1: -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions > -fkeep-inline-functions >
RE: SIGSEGV issue
Hi Andrew, I just want to thank you for all the pieces of info you provided. I am sure these top posting exchanges will at least help people choose the best ARM toolchain for their java development. I hope they will not be confused if I confused them in any manner. :-) Best Regards, David Sayada. -Original Message- From: Andrew Haley [mailto:[EMAIL PROTECTED] Sent: Thursday, September 06, 2007 12:49 PM To: David Sayada Cc: classpath@gnu.org; 'Amnon David' Subject: RE: SIGSEGV issue David Sayada writes: > Hi Andrew, > > Opening your link, I have noticed that the fcheck-references is defined for > arm-elf CPU. Also the arm-elf family is compatible with the processor I am > working with (PXA270). Then I will build a new toolchain for arm-elf based > on gcc 4.1.2 and make new tests. This top-posting is very confusing. Please stop. This is what matters: arm*-linux* ) slow_pthread_self=no can_unwind_signal=no CHECKREFSPEC=-fcheck-references DIVIDESPEC=-fuse-divide-subroutine ;; > > What do you think? It might work. Andrew. > > Best Regards, > David Sayada. > > -Original Message- > From: Andrew Haley [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 06, 2007 12:21 PM > To: David Sayada > Cc: classpath@gnu.org; 'Amnon David' > Subject: RE: SIGSEGV issue > > David Sayada writes: > > > > Reading specs from > > > /opt/crosstool/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux-gnu/bin/../lib/gcc/ar > > > m-unknown-linux-gnu/4.1.2/../../../../arm-unknown-linux-gnu/lib/libgcj.spec > > rename spec lib to liborig > > Target: arm-unknown-linux-gnu > > Configured with: > > > /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.1.2-glibc-2.3.2/g > > cc-4.1.2/configure --target=arm-unknown-linux-gnu > > --host=i686-host_pc-linux-gnu > > --prefix=/opt/crosstool2/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux-gnu > > > --with-headers=/opt/crosstool2/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux-gnu/a > > rm-unknown-linux-gnu/include > > > --with-local-prefix=/opt/crosstool2/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux- > > gnu/arm-unknown-linux-gnu --disable-nls --enable-threads=posix > > --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++,java > > --enable-shared --enable-c99 --enable-long-long > > Thread model: posix > > gcc version 4.1.2 > > > > The cross toolchain has been compiled with crosstool 0.43 from Dan Kegel. > > OK, it looks like the toolchain is totally misconfigured. My guess is > that this version of gcj on ARM doesn't work at all. > > You need -fcheck-references in that spec file, and the whole library > needs to be compiled with it. I have no idea whether gcj 4.1.2 ever > worked on ARM; I'm beginning to think not. > > Have a good look at > > http://gcc.gnu.org/svn/gcc/trunk/libjava/configure.host > > and make sure that the arm*-linux* sections are correct. > > This will help, but I suspect that gcj 4.1.2 will never work properly > on ARM. You need something much more recent. > > Andrew. > > > > > > # > # This spec file is read by gcj when linking. > # It is used to specify the standard libraries we need in order > # to link with libgcj. > # > %rename lib liborig > *lib: -lgcj -lm -lpthread-ldl %(libgcc) %(liborig) > > *jc1: -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions > -fkeep-inline-functions >
RE: SIGSEGV issue
Hi Andrew, Opening your link, I have noticed that the fcheck-references is defined for arm-elf CPU. Also the arm-elf family is compatible with the processor I am working with (PXA270). Then I will build a new toolchain for arm-elf based on gcc 4.1.2 and make new tests. What do you think? Best Regards, David Sayada. -Original Message- From: Andrew Haley [mailto:[EMAIL PROTECTED] Sent: Thursday, September 06, 2007 12:21 PM To: David Sayada Cc: classpath@gnu.org; 'Amnon David' Subject: RE: SIGSEGV issue David Sayada writes: > > Reading specs from > /opt/crosstool/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux-gnu/bin/../lib/gcc/ar > m-unknown-linux-gnu/4.1.2/../../../../arm-unknown-linux-gnu/lib/libgcj.spec > rename spec lib to liborig > Target: arm-unknown-linux-gnu > Configured with: > /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.1.2-glibc-2.3.2/g > cc-4.1.2/configure --target=arm-unknown-linux-gnu > --host=i686-host_pc-linux-gnu > --prefix=/opt/crosstool2/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux-gnu > --with-headers=/opt/crosstool2/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux-gnu/a > rm-unknown-linux-gnu/include > --with-local-prefix=/opt/crosstool2/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux- > gnu/arm-unknown-linux-gnu --disable-nls --enable-threads=posix > --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++,java > --enable-shared --enable-c99 --enable-long-long > Thread model: posix > gcc version 4.1.2 > > The cross toolchain has been compiled with crosstool 0.43 from Dan Kegel. OK, it looks like the toolchain is totally misconfigured. My guess is that this version of gcj on ARM doesn't work at all. You need -fcheck-references in that spec file, and the whole library needs to be compiled with it. I have no idea whether gcj 4.1.2 ever worked on ARM; I'm beginning to think not. Have a good look at http://gcc.gnu.org/svn/gcc/trunk/libjava/configure.host and make sure that the arm*-linux* sections are correct. This will help, but I suspect that gcj 4.1.2 will never work properly on ARM. You need something much more recent. Andrew. # # This spec file is read by gcj when linking. # It is used to specify the standard libraries we need in order # to link with libgcj. # %rename lib liborig *lib: -lgcj -lm -lpthread-ldl %(libgcc) %(liborig) *jc1: -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions
RE: SIGSEGV issue
Hi Andrew,
I hope that will help you.
This is why I get when typing arm-unknown-linux-gnu-gcj -v:
Reading specs from
/opt/crosstool/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux-gnu/bin/../lib/gcc/ar
m-unknown-linux-gnu/4.1.2/../../../../arm-unknown-linux-gnu/lib/libgcj.spec
rename spec lib to liborig
Target: arm-unknown-linux-gnu
Configured with:
/opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.1.2-glibc-2.3.2/g
cc-4.1.2/configure --target=arm-unknown-linux-gnu
--host=i686-host_pc-linux-gnu
--prefix=/opt/crosstool2/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux-gnu
--with-headers=/opt/crosstool2/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux-gnu/a
rm-unknown-linux-gnu/include
--with-local-prefix=/opt/crosstool2/gcc-4.1.2-glibc-2.3.2/arm-unknown-linux-
gnu/arm-unknown-linux-gnu --disable-nls --enable-threads=posix
--enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++,java
--enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.1.2
The cross toolchain has been compiled with crosstool 0.43 from Dan Kegel.
Best Regards,
David Sayada.
-Original Message-
From: Andrew Haley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 05, 2007 5:04 PM
To: David Sayada
Cc: classpath@gnu.org; 'Amnon David'
Subject: RE: SIGSEGV issue
David Sayada writes:
> I have been to catch the place where the SIGSEGV occurs, I hope this
stack
> trace will help you:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0004a284 in TCPServer.HMCServer.selectEventLoop() () at
> TCPServer/HMCServer.java:1849
> 1849int nReadBytes =
> client.read(info.m_readBuff);
Interesting. A SEGV should not be possible in compiled Java code on
ARM. I'm wondering if this might be a broken gcj installation.
Try
gcj -v
Then look at the line that begins
Reading specs from ...
Send a copy of that file to the list. It should look something like
#
# This spec file is read by gcj when linking.
# It is used to specify the standard libraries we need in order
# to link with libgcj.
#
%rename startfile startfileorig
*startfile: %(startfileorig)
%rename lib liborig
*lib: %{static-libgcj:-non_shared} %{s-bc-abi:-lgcj_bc;:-lgcj}
%{static-libgcj:-call_shared} -lm -lpthread -lrt -lz -ldl %(libgcc)
-lstdc++ %(liborig)
*jc1: -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc
-fkeep-inline-functions
Andrew.
libgcj.spec
Description: Binary data
RE: SIGSEGV issue
Hi Andrew, I have been to catch the place where the SIGSEGV occurs, I hope this stack trace will help you: Program received signal SIGSEGV, Segmentation fault. 0x0004a284 in TCPServer.HMCServer.selectEventLoop() () at TCPServer/HMCServer.java:1849 1849int nReadBytes = client.read(info.m_readBuff); Current language: auto; currently java (gdb) bt #0 0x0004a284 in TCPServer.HMCServer.selectEventLoop() () at TCPServer/HMCServer.java:1849 #1 0x0004ba34 in TCPServer.HMCServer.run() () at TCPServer/HMCServer.java:2055 #2 0x00134068 in _Jv_ThreadRun ([EMAIL PROTECTED]) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.1.2-glibc-2.3.2/g cc-4.1.2/libjava/java/lang/natThread.cc:297 #3 0x00137aa4 in really_start ([EMAIL PROTECTED]) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.1.2-glibc-2.3.2/g cc-4.1.2/libjava/posix-threads.cc:432 #4 0x002a01a0 in GC_start_routine (arg=) at /opt/test/crosstool-0.43/build/arm-unknown-linux-gnu/gcc-4.1.2-glibc-2.3.2/g cc-4.1.2/boehm-gc/pthread_support.c:1192 #5 0x40032a74 in pthread_start_thread () from /nfsroot/lib/libpthread.so.0 #6 0x40032aec in pthread_start_thread_event () from /nfsroot/lib/libpthread.so.0 Best Regards, David Sayada. -Original Message- From: Andrew Haley [mailto:[EMAIL PROTECTED] Sent: Thursday, August 30, 2007 11:52 AM To: David Sayada Cc: classpath@gnu.org; 'Amnon David' Subject: RE: SIGSEGV issue David Sayada writes: > To better understand what you are asking: > > - I need to look at the gcc-4.1.2 source to see if > gnu.java.nio.ServerSocketChannelImpl inherits from > java.nio.channels.SocketChannel? Sure. In particular, we need to know where exactly the code is that throws this exception. I see this: public final class ServerSocketChannelImpl extends ServerSocketChannel public abstract class ServerSocketChannel extends AbstractSelectableChannel public abstract class AbstractSelectableChannel extends SelectableChannel public abstract class SelectableChannel extends AbstractInterruptibleChannel public abstract class AbstractInterruptibleChannel implements Channel, InterruptibleChannel so it looks to me like this exception is correctly thrown. The cause is very likely: classpath/gnu/java/nio/SelectorImpl.java:292: if (((SocketChannel) key.channel ()).isConnected ()) but that code is surrounded by if (key.channel() instanceof SocketChannel) so it's very weird. > - "This is caused by a bug somewhere when generating stack traces", > you mean in classpath or libgcj in my case. I must then return you > an indication in your code? This is a bug of yours? Mine personally? I doubt it. The bug is probably in the ARM-specific code. We won't know until you've run the program in gdb and let us see where the SEGV occurs. Andrew. > -Original Message- > From: Andrew Haley [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 30, 2007 10:48 AM > To: David Sayada > Cc: classpath@gnu.org; 'Amnon David' > Subject: RE: SIGSEGV issue > > David Sayada writes: > > Hi Andrew, > > > > In fact, the exception I am receiving is the following one: > > > > java.lang.ClassCastException: > > > gnu.java.nio.ServerSocketChannelImpl cannot be cast to > > java.nio.channels.SocketChannel > > > > What can make such an exception to occur? > > Does gnu.java.nio.ServerSocketChannelImpl inherit from > java.nio.channels.SocketChannel? Have a look. > > > Also can it cause an application to terminate with signal SIGSEGV? > > No. This is caused by a bug somewhere when generating stack traces. > You need to run our app under gdb and tell us exactly where the segv > happens. > > Andrew. >
RE: SIGSEGV issue
Hi Andrew, I had some troubles to debug my multithreaded application through gdbserver. I think I have succeeded now, I may send you something tomorrow morning. Best Regards, David Sayada. -Original Message- From: Andrew Haley [mailto:[EMAIL PROTECTED] Sent: Thursday, August 30, 2007 11:52 AM To: David Sayada Cc: classpath@gnu.org; 'Amnon David' Subject: RE: SIGSEGV issue David Sayada writes: > To better understand what you are asking: > > - I need to look at the gcc-4.1.2 source to see if > gnu.java.nio.ServerSocketChannelImpl inherits from > java.nio.channels.SocketChannel? Sure. In particular, we need to know where exactly the code is that throws this exception. I see this: public final class ServerSocketChannelImpl extends ServerSocketChannel public abstract class ServerSocketChannel extends AbstractSelectableChannel public abstract class AbstractSelectableChannel extends SelectableChannel public abstract class SelectableChannel extends AbstractInterruptibleChannel public abstract class AbstractInterruptibleChannel implements Channel, InterruptibleChannel so it looks to me like this exception is correctly thrown. The cause is very likely: classpath/gnu/java/nio/SelectorImpl.java:292: if (((SocketChannel) key.channel ()).isConnected ()) but that code is surrounded by if (key.channel() instanceof SocketChannel) so it's very weird. > - "This is caused by a bug somewhere when generating stack traces", > you mean in classpath or libgcj in my case. I must then return you > an indication in your code? This is a bug of yours? Mine personally? I doubt it. The bug is probably in the ARM-specific code. We won't know until you've run the program in gdb and let us see where the SEGV occurs. Andrew. > -Original Message- > From: Andrew Haley [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 30, 2007 10:48 AM > To: David Sayada > Cc: classpath@gnu.org; 'Amnon David' > Subject: RE: SIGSEGV issue > > David Sayada writes: > > Hi Andrew, > > > > In fact, the exception I am receiving is the following one: > > > > java.lang.ClassCastException: > > > gnu.java.nio.ServerSocketChannelImpl cannot be cast to > > java.nio.channels.SocketChannel > > > > What can make such an exception to occur? > > Does gnu.java.nio.ServerSocketChannelImpl inherit from > java.nio.channels.SocketChannel? Have a look. > > > Also can it cause an application to terminate with signal SIGSEGV? > > No. This is caused by a bug somewhere when generating stack traces. > You need to run our app under gdb and tell us exactly where the segv > happens. > > Andrew. >
RE: SIGSEGV issue
Hi Andrew, Thanks for all these pieces of info and your help. I am making the test with gdb, I hope to provide you something ASAP. Many Thanks, David Sayada. -Original Message- From: Andrew Haley [mailto:[EMAIL PROTECTED] Sent: Thursday, August 30, 2007 11:52 AM To: David Sayada Cc: classpath@gnu.org; 'Amnon David' Subject: RE: SIGSEGV issue David Sayada writes: > To better understand what you are asking: > > - I need to look at the gcc-4.1.2 source to see if > gnu.java.nio.ServerSocketChannelImpl inherits from > java.nio.channels.SocketChannel? Sure. In particular, we need to know where exactly the code is that throws this exception. I see this: public final class ServerSocketChannelImpl extends ServerSocketChannel public abstract class ServerSocketChannel extends AbstractSelectableChannel public abstract class AbstractSelectableChannel extends SelectableChannel public abstract class SelectableChannel extends AbstractInterruptibleChannel public abstract class AbstractInterruptibleChannel implements Channel, InterruptibleChannel so it looks to me like this exception is correctly thrown. The cause is very likely: classpath/gnu/java/nio/SelectorImpl.java:292: if (((SocketChannel) key.channel ()).isConnected ()) but that code is surrounded by if (key.channel() instanceof SocketChannel) so it's very weird. > - "This is caused by a bug somewhere when generating stack traces", > you mean in classpath or libgcj in my case. I must then return you > an indication in your code? This is a bug of yours? Mine personally? I doubt it. The bug is probably in the ARM-specific code. We won't know until you've run the program in gdb and let us see where the SEGV occurs. Andrew. > -Original Message- > From: Andrew Haley [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 30, 2007 10:48 AM > To: David Sayada > Cc: classpath@gnu.org; 'Amnon David' > Subject: RE: SIGSEGV issue > > David Sayada writes: > > Hi Andrew, > > > > In fact, the exception I am receiving is the following one: > > > > java.lang.ClassCastException: > > > gnu.java.nio.ServerSocketChannelImpl cannot be cast to > > java.nio.channels.SocketChannel > > > > What can make such an exception to occur? > > Does gnu.java.nio.ServerSocketChannelImpl inherit from > java.nio.channels.SocketChannel? Have a look. > > > Also can it cause an application to terminate with signal SIGSEGV? > > No. This is caused by a bug somewhere when generating stack traces. > You need to run our app under gdb and tell us exactly where the segv > happens. > > Andrew. >
RE: SIGSEGV issue
Hi Andrew, To better understand what you are asking: - I need to look at the gcc-4.1.2 source to see if gnu.java.nio.ServerSocketChannelImpl inherits from java.nio.channels.SocketChannel? - "This is caused by a bug somewhere when generating stack traces", you mean in classpath or libgcj in my case. I must then return you an indication in your code? This is a bug of yours? Many Thanks, David Sayada. -Original Message- From: Andrew Haley [mailto:[EMAIL PROTECTED] Sent: Thursday, August 30, 2007 10:48 AM To: David Sayada Cc: classpath@gnu.org; 'Amnon David' Subject: RE: SIGSEGV issue David Sayada writes: > Hi Andrew, > > In fact, the exception I am receiving is the following one: > > java.lang.ClassCastException: > > gnu.java.nio.ServerSocketChannelImpl cannot be cast to > java.nio.channels.SocketChannel > > What can make such an exception to occur? Does gnu.java.nio.ServerSocketChannelImpl inherit from java.nio.channels.SocketChannel? Have a look. > Also can it cause an application to terminate with signal SIGSEGV? No. This is caused by a bug somewhere when generating stack traces. You need to run our app under gdb and tell us exactly where the segv happens. Andrew.
RE: SIGSEGV issue
Hi Andrew,
In fact, the exception I am receiving is the following one:
java.lang.ClassCastException:
> gnu.java.nio.ServerSocketChannelImpl cannot be cast to
java.nio.channels.SocketChannel
What can make such an exception to occur?
Also can it cause an application to terminate with signal SIGSEGV?
Many Thanks,
David Sayada.
-Original Message-
From: Andrew Haley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 29, 2007 2:59 PM
To: David Sayada
Cc: classpath@gnu.org; [EMAIL PROTECTED]; Amnon David
Subject: Re: SIGSEGV issue
David Sayada writes:
> Hi all,
>
> This email is following the last email I sent a few days ago about
SIGSEGV
> occurring in a java CNI application compiled with gcj 4.1.2 on a PXA270
> platform.
>
> I have traced the place in the code causing the exception, and please the
> see below the concerning code:
>
> if ( nReadBytes == 0 )
> {
> continue;
> }
>
> for (int i=0; i {
> info.m_strRequest +=
(char)info.m_readBuff.get(i);
> }
>
> I have read in some places that using UTF16 can be problematic with CNI.
Not to my knowledge.
> I think that the char cast automatically uses UTF16 instead of
> UTF8.
Java characters are Unicode by definition, so promoting a byte in this
way gets you a 16-bit Unicode Java character. That's perfectly
alright as long as you're sure that your byte is ASCII. It's
certainly not going to cause a SEGV.
> Am I right? Is there a way to write this code without using the
> char cast?
No. This code is grossly inefficient, though: you really ought to be
using StringBuffer.append(char) like this:
RequestBuffer.append((char)info.m_readBuff.get(i));
Andrew.
SIGSEGV issue
Hi all,
This email is following the last email I sent a few days ago about SIGSEGV
occurring in a java CNI application compiled with gcj 4.1.2 on a PXA270
platform.
I have traced the place in the code causing the exception, and please the
see below the concerning code:
if ( nReadBytes == 0 )
{
continue;
}
for (int i=0; i
SIGSEGV exception
Hi, I am facing a SIGSEGV exception coming from my application running on a PXA270 under linux and compiled with gcj 4.1.2 (arm). The exception seems to come from net/io/channel package: java.lang.ClassCastException: gnu.java.nio.ServerSocketChannelImpl cannot be cast to java.nio.channels.SocketChannel After this java exception is triggered, my application is killed receiving SIGSEGV. I would like to know if this is a classpath or libgcj issue. And if this is, has somebody fixed it in any gcc 4.1.x, 4.2.x or 4.3.x releases? Many Thanks, David S.
lightest classpath
Hi, I am successfully working with arm-uknown-linux-gnu-gcj in CNI by linking both RXTX and SQLite wrapper packages on my PXA 270 target. The only issue I have is the size of libgcj (45 M). Is there a way to compile the classpath with fewer components ? And then building a lightest libgcj ? Many thanks for your help. Best Regards, David Sayada.
