[Mono-dev] Exceptions-x86.c r140989 causes exceptions.exe test to crash on Mac x86
While trying to rebuild the latest Mono SVN, I noticed that the exceptions.exe was crashing during "make check". Digging a little deeper I reverted the latest change to exceptions-x86.c (svn update -r PREV mono/mono/mini/exceptions-x86.c) and everything passed. The crash from the test case using r of exceptions-x86.c is as follows: Test run: image=/Users/tom.philpot/External/mono-project/mono/mono/mini/exceptions.exe , opts= Stacktrace: at (wrapper managed-to-native) object.__icall_wrapper___emul_fconv_to_ovf_u8 (double) <0x4> at (wrapper managed-to-native) object.__icall_wrapper___emul_fconv_to_ovf_u8 (double) <0x> at Tests.test_0_byte_cast () <0x00318> Native stacktrace: 0 mono0x0008e0da mono_handle_native_sigsegv + 266 1 mono0x6eca mono_sigsegv_signal_handler + 298 2 libSystem.B.dylib 0x949402bb _sigtramp + 43 3 ??? 0x 0x0 + 4294967295 Debug info from gdb: warning: Trying to remove a section from the ordered section list that did not exist at 0x29c000. Attaching to process 53961. Reading symbols for shared libraries . done Reading symbols for shared libraries done 0x948f7f95 in read$UNIX2003 () 4 process 53961 thread 0x2703 0x948d42c2 in semaphore_wait_trap () 3 process 53961 thread 0x2303 0x948db46e in __semwait_signal () 2 process 53961 thread 0x1103 0x948d4286 in mach_msg_trap () * 1 process 53961 thread 0x717 0x948f7f95 in read$UNIX2003 () Thread 4 (process 53961 thread 0x2703): #0 0x948d42c2 in semaphore_wait_trap () #1 0x000f8013 in finalizer_thread (unused=0x0) at gc.c:1014 #2 0x001851ba in start_wrapper (data=0x60f4a0) at threads.c:657 #3 0x001b6225 in thread_start_routine (args=0x5dc434) at wthreads.c:286 #4 0x001d5483 in GC_start_routine (arg=0x593f60) at pthread_support.c:1390 #5 0x94905155 in _pthread_start () #6 0x94905012 in thread_start () Thread 3 (process 53961 thread 0x2303): #0 0x948db46e in __semwait_signal () #1 0x948db2ef in nanosleep$UNIX2003 () #2 0x00199b10 in collection_thread (unused=0x0) at collection.c:34 #3 0x94905155 in _pthread_start () #4 0x94905012 in thread_start () Thread 2 (process 53961 thread 0x1103): #0 0x948d4286 in mach_msg_trap () #1 0x948dba7c in mach_msg () #2 0x000c0dc4 in mach_exception_thread (arg=0x0) at mini-darwin.c:131 #3 0x001d5483 in GC_start_routine (arg=0x593f60) at pthread_support.c:1390 #4 0x94905155 in _pthread_start () #5 0x94905012 in thread_start () Thread 1 (process 53961 thread 0x717): #0 0x948f7f95 in read$UNIX2003 () #1 0x0008e1cb in mono_handle_native_sigsegv (signal=11, ctx=0xbfffec38) at mini-exceptions.c:1560 #2 0x6eca in mono_sigsegv_signal_handler (_dummy=11, info=0xbfffebf8, context=0xbfffec38) at mini.c:4583 #3 #4 0x0005a05e in mono_fconv_ovf_u8 (v=0) at jit-icalls.c:860 #5 0x016a23e7 in ?? () #6 0x016a1c49 in ?? () #7 0x00067d7d in mini_regression [inlined] () at driver.c:427 #8 0x00067d7d in mono_main (argc=16, argv=0xb0ec) at driver.c:484 #9 0x1ff6 in start () = Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Exceptions-x86.c r140989 causes exceptions.exe test to crash on Mac x86
Zoltan, Your patch broke x86-linux as well. On Tue, Sep 1, 2009 at 3:44 PM, Tom Philpot wrote: > While trying to rebuild the latest Mono SVN, I noticed that the > exceptions.exe was crashing during "make check". Digging a little deeper I > reverted the latest change to exceptions-x86.c (svn update -r PREV > mono/mono/mini/exceptions-x86.c) and everything passed. > > The crash from the test case using r of exceptions-x86.c is as follows: > > Test run: > > image=/Users/tom.philpot/External/mono-project/mono/mono/mini/exceptions.exe > , opts= > Stacktrace: > > at (wrapper managed-to-native) > object.__icall_wrapper___emul_fconv_to_ovf_u8 (double) <0x4> > at (wrapper managed-to-native) > object.__icall_wrapper___emul_fconv_to_ovf_u8 (double) <0x> > at Tests.test_0_byte_cast () <0x00318> > > Native stacktrace: > >0 mono0x0008e0da > mono_handle_native_sigsegv + 266 >1 mono0x6eca > mono_sigsegv_signal_handler + 298 >2 libSystem.B.dylib 0x949402bb _sigtramp + 43 >3 ??? 0x 0x0 + 4294967295 > > Debug info from gdb: > > warning: Trying to remove a section from the ordered section list that did > not exist at 0x29c000. > Attaching to process 53961. > Reading symbols for shared libraries . done > Reading symbols for shared libraries > > > done > 0x948f7f95 in read$UNIX2003 () > 4 process 53961 thread 0x2703 0x948d42c2 in semaphore_wait_trap () > 3 process 53961 thread 0x2303 0x948db46e in __semwait_signal () > 2 process 53961 thread 0x1103 0x948d4286 in mach_msg_trap () > * 1 process 53961 thread 0x717 0x948f7f95 in read$UNIX2003 () > > Thread 4 (process 53961 thread 0x2703): > #0 0x948d42c2 in semaphore_wait_trap () > #1 0x000f8013 in finalizer_thread (unused=0x0) at gc.c:1014 > #2 0x001851ba in start_wrapper (data=0x60f4a0) at threads.c:657 > #3 0x001b6225 in thread_start_routine (args=0x5dc434) at wthreads.c:286 > #4 0x001d5483 in GC_start_routine (arg=0x593f60) at pthread_support.c:1390 > #5 0x94905155 in _pthread_start () > #6 0x94905012 in thread_start () > > Thread 3 (process 53961 thread 0x2303): > #0 0x948db46e in __semwait_signal () > #1 0x948db2ef in nanosleep$UNIX2003 () > #2 0x00199b10 in collection_thread (unused=0x0) at collection.c:34 > #3 0x94905155 in _pthread_start () > #4 0x94905012 in thread_start () > > Thread 2 (process 53961 thread 0x1103): > #0 0x948d4286 in mach_msg_trap () > #1 0x948dba7c in mach_msg () > #2 0x000c0dc4 in mach_exception_thread (arg=0x0) at mini-darwin.c:131 > #3 0x001d5483 in GC_start_routine (arg=0x593f60) at pthread_support.c:1390 > #4 0x94905155 in _pthread_start () > #5 0x94905012 in thread_start () > > Thread 1 (process 53961 thread 0x717): > #0 0x948f7f95 in read$UNIX2003 () > #1 0x0008e1cb in mono_handle_native_sigsegv (signal=11, ctx=0xbfffec38) at > mini-exceptions.c:1560 > #2 0x6eca in mono_sigsegv_signal_handler (_dummy=11, info=0xbfffebf8, > context=0xbfffec38) at mini.c:4583 > #3 > #4 0x0005a05e in mono_fconv_ovf_u8 (v=0) at jit-icalls.c:860 > #5 0x016a23e7 in ?? () > #6 0x016a1c49 in ?? () > #7 0x00067d7d in mini_regression [inlined] () at driver.c:427 > #8 0x00067d7d in mono_main (argc=16, argv=0xb0ec) at driver.c:484 > #9 0x1ff6 in start () > > = > Got a SIGSEGV while executing native code. This usually indicates > a fatal error in the mono runtime or one of the native libraries > used by your application. > = > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] when will full-aot be supported on windows?
Aras Pranckevicius-3 wrote: > > Why not just dynamically link to Mono (LGPL compatible), and provide > all the necessary files along with your application? That is, do not > require Mono to be installed, instead just "bundle" it with your > application. Works for us (at Unity) really well, and the bare minimum > footprint (Mono DLL, mscorlib, config files) is something like 1.5 MB > compressed. > That is really great to hear as well. In reference to my own thread, http://www.nabble.com/Mono-and-the-LSB%2C-or-self-contained-installations-td25193025.html, do you need to build it in a special way? Or just cherry pick the binaries and away you go? Thanks, J -- View this message in context: http://www.nabble.com/when-will-full-aot-be-supported-on-windows--tp25218286p25244298.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Exceptions-x86.c r140989 causes exceptions.exe test to crash on Mac x86
Fixed in r141069 Thanks -g On 1-Sep-09, at 2:44 PM, Tom Philpot wrote: > While trying to rebuild the latest Mono SVN, I noticed that the > exceptions.exe was crashing during "make check". Digging a little > deeper I > reverted the latest change to exceptions-x86.c (svn update -r PREV > mono/mono/mini/exceptions-x86.c) and everything passed. > > The crash from the test case using r of exceptions-x86.c is as > follows: > > Test run: > image=/Users/tom.philpot/External/mono-project/mono/mono/mini/ > exceptions.exe > , opts= > Stacktrace: > > at (wrapper managed-to-native) > object.__icall_wrapper___emul_fconv_to_ovf_u8 (double) <0x4> > at (wrapper managed-to-native) > object.__icall_wrapper___emul_fconv_to_ovf_u8 (double) <0x> > at Tests.test_0_byte_cast () <0x00318> > > Native stacktrace: > >0 mono0x0008e0da > mono_handle_native_sigsegv + 266 >1 mono0x6eca > mono_sigsegv_signal_handler + 298 >2 libSystem.B.dylib 0x949402bb _sigtramp + 43 >3 ??? 0x 0x0 + 4294967295 > > Debug info from gdb: > > warning: Trying to remove a section from the ordered section list > that did > not exist at 0x29c000. > Attaching to process 53961. > Reading symbols for shared libraries . done > Reading symbols for shared libraries > > done > 0x948f7f95 in read$UNIX2003 () > 4 process 53961 thread 0x2703 0x948d42c2 in semaphore_wait_trap () > 3 process 53961 thread 0x2303 0x948db46e in __semwait_signal () > 2 process 53961 thread 0x1103 0x948d4286 in mach_msg_trap () > * 1 process 53961 thread 0x717 0x948f7f95 in read$UNIX2003 () > > Thread 4 (process 53961 thread 0x2703): > #0 0x948d42c2 in semaphore_wait_trap () > #1 0x000f8013 in finalizer_thread (unused=0x0) at gc.c:1014 > #2 0x001851ba in start_wrapper (data=0x60f4a0) at threads.c:657 > #3 0x001b6225 in thread_start_routine (args=0x5dc434) at wthreads.c: > 286 > #4 0x001d5483 in GC_start_routine (arg=0x593f60) at > pthread_support.c:1390 > #5 0x94905155 in _pthread_start () > #6 0x94905012 in thread_start () > > Thread 3 (process 53961 thread 0x2303): > #0 0x948db46e in __semwait_signal () > #1 0x948db2ef in nanosleep$UNIX2003 () > #2 0x00199b10 in collection_thread (unused=0x0) at collection.c:34 > #3 0x94905155 in _pthread_start () > #4 0x94905012 in thread_start () > > Thread 2 (process 53961 thread 0x1103): > #0 0x948d4286 in mach_msg_trap () > #1 0x948dba7c in mach_msg () > #2 0x000c0dc4 in mach_exception_thread (arg=0x0) at mini-darwin.c:131 > #3 0x001d5483 in GC_start_routine (arg=0x593f60) at > pthread_support.c:1390 > #4 0x94905155 in _pthread_start () > #5 0x94905012 in thread_start () > > Thread 1 (process 53961 thread 0x717): > #0 0x948f7f95 in read$UNIX2003 () > #1 0x0008e1cb in mono_handle_native_sigsegv (signal=11, > ctx=0xbfffec38) at > mini-exceptions.c:1560 > #2 0x6eca in mono_sigsegv_signal_handler (_dummy=11, > info=0xbfffebf8, > context=0xbfffec38) at mini.c:4583 > #3 > #4 0x0005a05e in mono_fconv_ovf_u8 (v=0) at jit-icalls.c:860 > #5 0x016a23e7 in ?? () > #6 0x016a1c49 in ?? () > #7 0x00067d7d in mini_regression [inlined] () at driver.c:427 > #8 0x00067d7d in mono_main (argc=16, argv=0xb0ec) at driver.c:484 > #9 0x1ff6 in start () > > = > Got a SIGSEGV while executing native code. This usually indicates > a fatal error in the mono runtime or one of the native libraries > used by your application. > = > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] valgrind and mono
Hi,
I understand from here http://mono-project.com/Debugging that I should
be able to use valgrind with mono.
However it seems to report stack corruption for simple handled
exceptions like this:
try {
Control c = null;
c.Focus();
}
catch {
}
finally {
}
valgrind reports:
==14971== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==14971== Thread 1 return signal frame corrupted. Killing process.
valgrind --tool=memcheck -v --leak-check=full --log-file=log
--smc-check=all --suppressions=mono.supp mono MyTest.exe
My valgrind is valgrind-3.4.1-Debian and my mono from svn is r139201.
Has anyone else experienced this?
Any solutions / workarounds?
Thanks
Tom
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] valgrind and mono
Hi,
Mono uses sigaltstack() to handle some signals, and valgrind is probably
confused by
that. Try configuring mono with --with-sigaltstack=no.
Zoltan
On Wed, Sep 2, 2009 at 2:11 AM, Tom Hindle wrote:
> Hi,
>
> I understand from here http://mono-project.com/Debugging that I should
> be able to use valgrind with mono.
>
> However it seems to report stack corruption for simple handled
> exceptions like this:
>
> try {
>Control c = null;
>c.Focus();
> }
> catch {
> }
> finally {
> }
>
> valgrind reports:
> ==14971== Address 0x0 is not stack'd, malloc'd or (recently) free'd
> ==14971== Thread 1 return signal frame corrupted. Killing process.
>
> valgrind --tool=memcheck -v --leak-check=full --log-file=log
> --smc-check=all --suppressions=mono.supp mono MyTest.exe
>
>
> My valgrind is valgrind-3.4.1-Debian and my mono from svn is r139201.
>
> Has anyone else experienced this?
>
> Any solutions / workarounds?
>
> Thanks
> Tom
>
>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
