Yes.
Zoltan
On Thu, Aug 15, 2013 at 1:23 AM, Bassam Tabbara <bas...@symform.com> wrote:
> If I disable the assert the application continues to work and completes:
>
>
> https://github.com/symform/mono/commit/859aa7fcd0fcb9017f45d8bfb59cfe8907f413d3
>
> If I understand things correctly if the patching fails on the call-site
> the trampoline will remain in place and the code will have to get JITed
> again on the next invocation. This seems like a better outcome than
> asserting.
>
> Does this seem like a reasonable workaround until you find the root
> cause here?
>
> From: Bassam Tabbara <bas...@symform.com>
> Date: Wednesday, August 14, 2013 1:07 PM
>
> To: Zoltan Varga <var...@gmail.com>
> Cc: "mono-devel-list@lists.ximian.com" <mono-devel-list@lists.ximian.com>
> Subject: Re: [Mono-dev] Assert in mini-arm.c
>
> I tried increasing MIN_PAGES in mono-codeman.c to 32 and still didn't
> help.
>
> Is there another workaround that could help here?
>
> From: Bassam Tabbara <bas...@symform.com>
> Date: Wednesday, August 14, 2013 12:26 AM
> To: Zoltan Varga <var...@gmail.com>
> Cc: "mono-devel-list@lists.ximian.com" <mono-devel-list@lists.ximian.com>
> Subject: Re: [Mono-dev] Assert in mini-arm.c
>
> Here it is. Note that this run was compiled with BIND_ROOM set to 4 as
> you recommended.
>
> #2 0x00172c44 in arm_patch (code=0x407b05c8
> "\357\376\377\353\367\377\377\352\340A-\351\004\320M\342", target=0x5da1ebe0
> "\r\300\240\341\360_-\351(\320M\342$\311\377\353") at mini-arm.c:3530
>
> (gdb) x/10i code
> 0x407b05c8: bl 0x407b018c
> 0x407b05cc: b 0x407b05b0
> 0x407b05d0: push {r5, r6, r7, r8, lr}
> 0x407b05d4: sub sp, sp, #4
> 0x407b05d8: mov r5, r0
> 0x407b05dc: mov r6, r1
> 0x407b05e0: mov r7, r2
> 0x407b05e4: orr r0, r5, r6
> 0x407b05e8: and r0, r0, #3
> 0x407b05ec: cmp r0, #0
>
> (gdb) x/10i target
> 0x5da1ebe0: mov r12, sp
> 0x5da1ebe4: push {r4, r5, r6, r7, r8, r9, r10, r11, r12, lr}
> 0x5da1ebe8: sub sp, sp, #40 ; 0x28
> 0x5da1ebec: bl 0x5da11084
> 0x5da1ebf0: add r1, sp, #0
> 0x5da1ebf4: str r0, [r1, #4]
> 0x5da1ebf8: ldr r12, [r0]
> 0x5da1ebfc: str r12, [r1]
> 0x5da1ec00: str r1, [r0]
> 0x5da1ec04: str sp, [r1, #12]
>
> Let me know if there is anything else I can provide.
>
> From: Zoltan Varga <var...@gmail.com>
> Date: Tuesday, August 13, 2013 5:15 PM
> To: Bassam Tabbara <bas...@symform.com>
> Cc: "mono-devel-list@lists.ximian.com" <mono-devel-list@lists.ximian.com>
> Subject: Re: [Mono-dev] Assert in mini-arm.c
>
> I meant frame #2, i.e.
> #2 0x00172ca8 in arm_patch
>
> Zoltan
>
>
> On Wed, Aug 14, 2013 at 2:14 AM, Zoltan Varga <var...@gmail.com> wrote:
>
>> Hi,
>>
>> Can you see whats at 'code' and 'target' at frame #3, i.e.
>> x/10i code
>> x/10i target
>>
>> Zoltan
>>
>>
>> On Wed, Aug 14, 2013 at 1:48 AM, Bassam Tabbara <bas...@symform.com>wrote:
>>
>>> Unfortunately that did not help. Still seeing the problem. I'm still
>>> working on a test case but I'm not having much luck so far in getting an
>>> isolated repro.
>>>
>>> I was able to get a debugger attached to the process right when
>>> handle_thunk asserts, and there were 6 threads with the following call
>>> stack:
>>>
>>> Thread 5 (Thread 0x558ff460 (LWP 9201)):
>>> #0 handle_thunk (method=0x0, domain=0x4ce44e58, absolute=1,
>>> code=0x427f8f08 "Q\364\377\353\367\377\377\352",
>>> target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353",
>>> dyn_code_mp=0x0) at mini-arm.c:3373
>>> #1 0x00172764 in arm_patch_general (method=0x0, domain=0x0,
>>> code=0x427f8f08 "Q\364\377\353\367\377\377\352",
>>> target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353",
>>> dyn_code_mp=0x0) at mini-arm.c:3425
>>> #2 0x00172ca8 in arm_patch (code=0x427f8f08
>>> "Q\364\377\353\367\377\377\352", target=0x511f02a0
>>> "\r\300\240\341\360_-\351(\320M\342k\323\377\353") at mini-arm.c:3536
>>> #3 0x001830bc in mono_arch_patch_callsite (method_start=0x427f8e90
>>> "\r\300\240\341\360_-\351(\320M\342", code_ptr=0x427f8f0c
>>> "\367\377\377\352",
>>> addr=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353")
>>> at tramp-arm.c:87
>>> #4 0x0012c5c8 in common_call_trampoline (regs=0x558fd090,
>>> code=0x427f8f0c "\367\377\377\352", m=0x2a08a000, tramp=0x2e4bcd80
>>> "x\320\217U", vt=0x0, vtable_slot=0x0,
>>> need_rgctx_tramp=0) at mini-trampolines.c:673
>>> #5 0x0012c67c in mono_magic_trampoline (regs=0x558fd090,
>>> code=0x427f8f0c "\367\377\377\352", arg=0x2a08a000, tramp=0x2e4bcd80
>>> "x\320\217U") at mini-trampolines.c:690
>>> #6 0x403f5060 in ?? ()
>>> #7 0x403f5060 in ?? ()
>>>
>>> All 6 threads where in a trampoline. The method in frame 4 was
>>> "mono_thread_interruption_checkpoint" for all six threads.
>>>
>>> Does this give you any more clues into what is going on?
>>>
>>> This is blocking our upgrade to mono-3-0 unfortunately. Any help will
>>> be greatly appreciated.
>>>
>>> From: Zoltan Varga <var...@gmail.com>
>>> Date: Tuesday, August 13, 2013 3:20 AM
>>> To: Bassam Tabbara <bas...@symform.com>
>>> Cc: "mono-devel-list@lists.ximian.com" <mono-devel-list@lists.ximian.com
>>> >
>>> Subject: Re: [Mono-dev] Assert in mini-arm.c
>>>
>>> Hi,
>>>
>>> This is a JIT problem, it will be hard to track down without a
>>> testcase. You can try changing this line in mono/utils/mono-codeman.c:
>>>
>>> #define BIND_ROOM 8
>>>
>>> to
>>>
>>> #define BIND_ROOM 4
>>>
>>> It might fix the issue.
>>>
>>> Zoltan
>>>
>>>
>>> On Tue, Aug 13, 2013 at 7:44 AM, Bassam Tabbara <bas...@symform.com>wrote:
>>>
>>>> Folks,
>>>>
>>>> Any insights into why the assert would trigger? Is this a resource
>>>> exhaustion issue, or is specific to certain code that is being JITed? I
>>>> need someone to point me in the right direction. I'm able to reproduce this
>>>> but only in the context of our application. This did not happen with the
>>>> mono-2-10 branch.
>>>>
>>>> Thanks!
>>>> Bassam
>>>>
>>>> From: Bassam Tabbara <bas...@symform.com>
>>>> Date: Friday, August 9, 2013 10:36 AM
>>>> To: "mono-devel-list@lists.ximian.com" <
>>>> mono-devel-list@lists.ximian.com>
>>>> Subject: [Mono-dev] Assert in mini-arm.c
>>>>
>>>> Hello,
>>>>
>>>> I'm seeing the following assert on an armv5tel using latest from
>>>> master:
>>>>
>>>> http://pastebin.com/raw.php?i=CLDXxiPy
>>>>
>>>> I'm trying to get an isolated repro but it proving to be elusive. In
>>>> our full test runs we see this all the time.
>>>>
>>>> Any tips on how to debug this further?
>>>>
>>>> Thanks!
>>>> Bassam
>>>>
>>>> _______________________________________________
>>>> 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
