[Mono-dev] HEADS UP: Linear IR branch merge

Zoltan Varga vargaz at gmail.com
Sun Jul 27 10:37:23 EDT 2008 

Hi,

  This is now fixed in SVN. Thanks for reporting it.

            Zoltan

On Sun, Jul 27, 2008 at 4:03 PM, Cedric Vivier <cedricv at neonux.com> wrote:
> On Sun, Jul 27, 2008 at 9:43 PM, Zoltan Varga <vargaz at gmail.com> 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 <cedricv at neonux.com> 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 <vargaz at gmail.com> 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 at lists.ximian.com
>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>
>>>
>>
>

More information about the Mono-devel-list mailing list