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