Hi, This is now fixed in SVN. Thanks for reporting it.
Zoltan On Sun, Jul 27, 2008 at 4:03 PM, Cedric Vivier <[EMAIL PROTECTED]> wrote: > On Sun, Jul 27, 2008 at 9:43 PM, Zoltan Varga <[EMAIL PROTECTED]> wrote: >> Does this happen with latest mono SVN HEAD ? If so, what is the output of >> mono --version ? > > Yeah, I´ve just tried it again with r108927 > > Mono JIT compiler version 2.0 ( r) > Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com > TLS: __thread > GC: Included Boehm (with typed GC) > SIGSEGV: altstack > Notifications: epoll > Architecture: x86 > Disabled: none > > > >> Zoltan >> >> On Sun, Jul 27, 2008 at 12:30 PM, Cedric Vivier <[EMAIL PROTECTED]> wrote: >>> Hi Zoltan, >>> >>> It has probably been already reported (though I cannot find it in the >>> bugzilla) but there is a crash with the new JIT when starting Tomboy >>> and other applications using NDesk.Dbus (latest stable versions of >>> both). >>> >>> Stacktrace: >>> at (wrapper managed-to-native) >>> System.Reflection.MonoMethod.InternalInvoke >>> (object,object[],System.Exception&) <0x00004> >>> at (wrapper managed-to-native) >>> System.Reflection.MonoMethod.InternalInvoke >>> (object,object[],System.Exception&) <0xffffffff> >>> at System.Reflection.MonoMethod.Invoke >>> (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) >>> <0x0008e> >>> at System.Reflection.MethodBase.Invoke (object,object[]) <0x0001c> >>> at System.Reflection.Emit.DynamicMethod.Invoke >>> (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) >>> <0x00050> >>> at System.Reflection.MethodBase.Invoke (object,object[]) <0x0001c> >>> at NDesk.DBus.MessageWriter.WriteValueType (object,System.Type) <0x0005f> >>> at NDesk.DBus.Message.GetHeaderData () <0x0009d> >>> at NDesk.DBus.Connection.WriteMessage (NDesk.DBus.Message) <0x00019> >>> at NDesk.DBus.Connection.SendWithReply (NDesk.DBus.Message) <0x0006f> >>> at NDesk.DBus.Connection.SendWithReplyAndBlock (NDesk.DBus.Message) >>> <0x0000d> >>> at NDesk.DBus.BusObject.SendMethodCall >>> (string,string,string,NDesk.DBus.MessageWriter,System.Type,System.Exception&) >>> <0x00100> >>> at IBusProxy.Hello () <0x0004a> >>> at NDesk.DBus.Bus.Register () <0x0001d> >>> at NDesk.DBus.Bus..ctor (string) <0x0002e> >>> at NDesk.DBus.Bus.Open (string) <0x00051> >>> at NDesk.DBus.Bus.get_System () <0x0004c> >>> at NDesk.DBus.BusG.Init () <0x00012> >>> at Tomboy.RemoteControlProxy.Register (Tomboy.NoteManager) <0x0000a> >>> at Tomboy.Tomboy.RegisterRemoteControl (Tomboy.NoteManager) <0x00015> >>> at Tomboy.Tomboy.Main (string[]) <0x000f5> >>> at (wrapper runtime-invoke) >>> Tomboy.Tomboy.runtime_invoke_void_string[] >>> (object,intptr,intptr,intptr) <0xffffffff> >>> >>> Native stacktrace: >>> mono [0x806e178] >>> Cannot access memory at address 0x23 >>> >>> Debug info from gdb: >>> Thread 1 (Thread 0xb7d3f960 (LWP 25863)): >>> #0 0xffffe424 in __kernel_vsyscall () >>> #1 0xb7e54807 in syscall () from /lib/tls/i686/cmov/libc.so.6 >>> #2 0x0806e212 in mono_handle_native_sigsegv (signal=11, >>> ctx=0xb7c0ed0c) at mini-exceptions.c:1294 >>> #3 0x080872a0 in mono_arch_handle_altstack_exception >>> (sigctx=0xb7c0ed0c, fault_addr=0x27, stack_ovf=0) at >>> exceptions-x86.c:855 >>> #4 <signal handler called> >>> #5 mono_method_to_ir2 (cfg=0xa13d600, method=0xa15d8b0, >>> start_bblock=0xa148314, end_bblock=0xa1483ac, return_var=0x0, >>> dont_inline=0xa15dd00, >>> inline_args=0x0, inline_offset=0, is_virtual_call=0) at >>> method-to-ir.c:7536 >>> #6 0x081c0ac6 in mini_method_compile (method=0xa15d8b0, >>> opts=30501375, domain=0x34ea0, run_cctors=<value optimized out>, >>> compile_aot=<value optimized out>, parts=0) at mini.c:13232 >>> #7 0x081c28c0 in mono_jit_compile_method (method=0xa15d8b0) at mini.c:13917 >>> #8 0x081c3192 in mono_jit_runtime_invoke (method=0xa15d8b0, obj=0x0, >>> params=0xbf9ff8f0, exc=0x0) at mini.c:14263 >>> #9 0x0813e5d3 in mono_runtime_invoke_array (method=0xa15d8b0, >>> obj=0x0, params=0x24d5a0, exc=0x0) at object.c:3251 >>> #10 0x080e30c1 in ves_icall_InternalInvoke (method=0x47c8b8, this=0x0, >>> params=0x24d5a0, exc=0xbf9ffa28) at icall.c:3034 >>> >>> >>> Everything works fine when using MONO_COUNT=0. >>> >>> >>> >>> >>> On Thu, Jul 24, 2008 at 4:21 AM, Zoltan Varga <[EMAIL PROTECTED]> wrote: >>>> Hi All, >>>> >>>> The merge is now done, the current testing status is the following: >>>> - x86/amd64 linux seems to be in good shape, the other >>>> architectures/OSes have some problems >>>> >>>> I would like to ask people to try out the new code, and report >>>> problems either by >>>> replying to this mail or by using bugzilla. >>>> >>>> To help track down problems, the new JIT actually includes the old >>>> one, and there is >>>> an env variable called MONO_COUNT which if set determines the number of >>>> methods compiled by the new JIT. So running your app with MONO_COUNT=0 will >>>> use the old JIT. This variable can be used to determine the exact >>>> method which is >>>> miscompiled by the new JIT using a binary search, ie.: >>>> >>>> MONO_COUNT=10000 mono app.exe -> fail >>>> MONO_COUNT=5000 mono app.exe -> fail >>>> MONO_COUNT=2500 mono app.exe -> success >>>> MONO_COUNT=3500 mono app.exe >>>> >>>> etc. >>>> >>>> When the new JIT code is deemed stable enough, the old JIT code and this >>>> env >>>> variable will be removed. >>>> >>>> In case anyone wants to revert their tree to before the merge, the before >>>> merge >>>> revision is r108475. >>>> >>>> Zoltan >>>> >>>>> On Tue, 2008-07-22 at 01:09 +0200, Zoltan Varga wrote: >>>>>> Hi All, >>>>>> >>>>>> Now that we have branched for mono 2.0, we would like to merge the >>>>>> work done on the linear IR branch to svn HEAD. The >>>>>> linear IR branch was created in 2005 October to explore some ideas on >>>>>> how to make our JIT simpler and how to make >>>>>> it generate better code. A lot of work has been put into the branch >>>>>> over the years, and now we are ready to merge it. >>>>>> Changes of this magnitude are never easy, so svn head might be a bit >>>>>> unstable for a few weeks as we work out the problems. Documentation >>>>>> for the new JIT and some benchmarks can be found at >>>>>> http://www.mono-project.com/Linear_IL >>>>>> >>>>>> I plan to do the merge tomorrow. Until then, please avoid checking in >>>>>> code to the mono/mini directory so as to not interfere with the merge. >>>>>> >>>>> >>>>> This is great news! Do we have a list of architectures that will be >>>>> supported, and more importantly a list of architectures that will be >>>>> broken when you do the merge? >>>>> >>>>> If I remember correctly, ARM, x86, x86-64, sparc, and itanium are ported >>>>> already? >>>>> >>>>> Thanks >>>>> >>>>> -g >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> 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