Created attachment 24992 [details] try to resolve 'o1' class on runtime, and got sigsegv when referenced class(oo1) is not found in classpath, it throwed classnotfoundexception. but it sigsegved Starting program: /usr/i686-pc-mingw32/java/bin/i686-pc-mingw32-gij -cp . foobar --verbose [New Thread 7704.0x1af8] [New Thread 7704.0x2b60] Program received signal SIGSEGV, Segmentation fault. 0x696cfc4a in java::lang::Object::getClass (this=0x0) at ../.././libjava/java/lang/natObject.cc:58 58 return (*dt)->clas; (gdb) bt #0 0x696cfc4a in java::lang::Object::getClass (this=0x0) at ../.././libjava/java/lang/natObject.cc:58 #1 0x696b8bbf in _Jv_InterpMethod::check_handler (this=0xe12f60, pc=0x22e8d8, meth=0xe12f60, ex=0x0) at ../.././libjava/interpret.cc:1463 #2 0x696a99f5 in _Jv_InterpMethod::run (retp=0x22f104, args=0x22f124, meth=0xe12f60) at ../.././libjava/interpret-run.cc:2676 #3 0x696a2251 in _Jv_InterpMethod::run_normal (ret=0x22f104, args=0x22f124, __this=0xe12f60) at ../.././libjava/interpret.cc:358 #4 0x6a432ee5 in ffi_closure_raw_SYSV () at ../.././libffi/src/x86/win32.S:695 #5 0x6a432d37 in ffi_call_win32 () at ../.././libffi/src/x86/win32.S:424 #6 0x6a432d13 in ffi_raw_call (cif=0xbf0b24, fn=0xe30098, rvalue=0x22f4e0, fake_avalue=0x22f1c0) at ../.././libffi/src/x86/ffi.c:647 #7 0x696a351f in _Jv_InterpMethod::run (retp=0x22fd20, args=0x22fd40, meth=0xab8e60) at ../.././libjava/interpret-run.cc:611 #8 0x696a237a in _Jv_InterpMethod::run_class (ret=0x22fd20, args=0x22fd40, __this=0xab8e60) at ../.././libjava/interpret.cc:407 #9 0x6a432ee5 in ffi_closure_raw_SYSV () at ../.././libffi/src/x86/win32.S:695 #10 0x696c282c in gnu::java::lang::MainThread::call_main (this=0xbfdf60) at ../.././libjava/gnu/java/lang/natMainThread.cc:54 #11 0x6973c37d in gnu.java.lang.MainThread.run()void (this=@bfdf60) at /tmp/gcc/libjava/gnu/java/lang/MainThread.java:106 #12 0x696d4d4d in _Jv_ThreadRun (thread=0xbfdf60) at ../.././libjava/java/lang/natThread.cc:335 ---Type <return> to continue, or q <return> to quit--- #13 0x69684e9b in _Jv_RunMain (vm_args=0x22fef4, klass=0x0, name=0x3d8925 "foobar", argc=0x2, argv=0x3d89fc, is_jar=0x0) at ../.././libjava/prims.cc:1789 #14 0x66bc24b0 in _fu0___ZN3gcj13verifyClassesE () at ../.././libjava/gij.cc:333 #15 0x004010fd in __mingw_CRTStartup () at ../../.././winsup/mingw/crt1.c:244 #16 0x00000408 in ?? () #17 0x7ffd4000 in ?? () #18 0x00000000 in ?? () (gdb) and _Jv_Throw doesn't seem to pass throwable as argument of unwind_raiseexception, as a consequence, catch(Throwable e){someoperaton(e);} leads SIGSEGV.
Hmm, this might be a duplicate for already fixed PR/50053. Could you please check, if you still have this issue here with current trunk version. Thanks
(In reply to comment #1) > Hmm, this might be a duplicate for already fixed PR/50053. Could you please > check, if you still have this issue here with current trunk version. > > Thanks Starting program: /tmp/gcc/i686-pc-mingw32/libjava/.libs/gij.exe /tmp/gcc/libjava/testsuite/libjava.lang/foobar.class [New Thread 9088.0x1188] [New Thread 9088.0x2760] [Inferior 1 (process 9088) exited with code 01] (gdb) just exists with silent message. without sigsegv
in libjava/exception.cc /* The object being thrown. Compiled code expects this to be immediately before the generic exception header. Which is complicated by the fact that _Unwind_Exception is ((aligned)). */ Starting program: /tmp/gcc/i686-pc-mingw32/libjava/testsuite/.libs/PR218 [New Thread 6064.0x1e4c] Breakpoint 13, _Jv_Throw (value=0xa9ba08) at ../.././libjava/exception.cc:118 118 _Unwind_RaiseException (&xh->unwindHeader); (gdb) p ((int)&xh->unwindHeader-(int)&xh->value) $19 = 0xc It seems that padding was unsuccessful. following is version info. Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.7.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ./configure --config-cache --prefix=/usr --disable-win32-registry --enable-threads=win32 --enable-languages=c,c++,lto,fortran --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp --enable-cloog-backend=isl LTLDFLAGS=-no-undefined lt_cv_deplibs_check_method=pass_all : (reconfigured) ./configure --config-cache --prefix=/usr --disable-win32-registry --enable-threads=win32 --enable-languages=c,c++,lto,fortran --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp --enable-cloog-backend=isl LTLDFLAGS=-no-undefined lt_cv_deplibs_check_method=pass_all Thread model: win32 gcc version 4.7.0 20120114 (experimental) (GCC)
Created attachment 26365 [details] proposed patch it fixes invalid padding that caused the bug. #include <cstddef> #define DEBUG 1 #include <cassert> #include <cstdlib> #include <cstdio> #include <iostream> typedef int* jthrowable,_Unwind_Ptr; struct alignment_test_struct { char space; char end[0] __attribute__((aligned)); }; struct java_exception_header { #define MEMBER_AT_FRONT \ _Unwind_Ptr* landingPad;\ int handlerSwitchValue; MEMBER_AT_FRONT struct _pad{MEMBER_AT_FRONT}; #undef MEMBER_AT_FRONT #define PADORZERO(x,y,z) (sizeof(x)<sizeof(y)?sizeof(y)-sizeof(x)+(z):0) char pad[PADORZERO(jthrowable,alignment_test_struct,PADORZERO(_pad,alignment_test_struct,0))]; #undef PADORZERO jthrowable __attribute__((packed)) value; int* unwindHeader; }; int main() { alignment_test_struct s; java_exception_header t; printf("%x\n",sizeof(alignment_test_struct)); int dat[]={offsetof(java_exception_header,pad),sizeof(java_exception_header::pad) ,offsetof(java_exception_header,value),sizeof(java_exception_header::value) ,offsetof(java_exception_header,unwindHeader),sizeof(java_exception_header::unwindHeader)}; printf("pad %x %x\n",dat[0],dat[1]); printf("value %x %x\n",dat[2],dat[3]); printf("header %x %x\n",dat[4],dat[5]); assert((dat[2]+dat[3])==dat[4]); return 0; } 10 pad 8 14 value 1c 4 header 20 4
Hmm, I assume issue is related to using of -mms-bitfields for 4.7 for windows-targets. Does the following patch fix the issue? Index: exception.cc =================================================================== --- exception.cc (revision 184105) +++ exception.cc (working copy) @@ -33,12 +33,18 @@ } #include "unwind.h" +#ifdef __MINGW32__ +__attribute__ ((gcc_struct)) +#endif struct alignment_test_struct { char space; char end[0] __attribute__((aligned)); }; +#ifdef __MINGW32__ +__attribute__ ((gcc_struct)) +#endif struct java_exception_header { /* Cache handler details between Phase 1 and Phase 2. */
Hmm, this might be a duplicate of PR52238
Could you please retest this bug. I assume it is a duplicate of PR52238, which was recently fixed.
(In reply to comment #7) > Could you please retest this bug. I assume it is a duplicate of PR52238, which > was recently fixed. yes, it's fixed. thank you.
mark as duplicate of 52238 *** This bug has been marked as a duplicate of bug 52238 ***