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<mailto:var...@gmail.com>>
Date: Tuesday, August 13, 2013 5:15 PM
To: Bassam Tabbara <bas...@symform.com<mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
<mono-devel-list@lists.ximian.com<mailto: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<mailto: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<mailto: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<mailto:var...@gmail.com>>
Date: Tuesday, August 13, 2013 3:20 AM
To: Bassam Tabbara <bas...@symform.com<mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
<mono-devel-list@lists.ximian.com<mailto: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<mailto: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<mailto:bas...@symform.com>>
Date: Friday, August 9, 2013 10:36 AM
To: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
<mono-devel-list@lists.ximian.com<mailto: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<mailto: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

Reply via email to