Yikes. Sorry about the multiple posts there. I should have realised the mail server was just down.
> On Mon, Feb 7, 2011 at 12:09 PM, Weeble <clockworksa...@gmail.com> wrote: >> I'm currently running Mono 2.6.7 on an ARM box (a Sheevaplug) running >> Linux. When I try to run unit tests that work on Windows-x86 with >> Microsoft's CLR and on Linux-x86 with Mono, they fail often (but not >> always) with an assertion: >> >> thunk failed for 0x40368c80 from 0x4f2a20d8 >> ERROR:mini-arm.c:2579:handle_thunk: assertion failed: (pdata.found == 1) > > I have been unable so far to extricate the native library to produce a > simple test case that reproduces this. However, I have now built Mono > 2.8.2 from source for the ARM device and edited in some extra > diagnostic output in mini-arm.c. It would appear that the when the > failure happens, handle_thunk uses search_thunk_slot to search for an > appropriate thunk slot, but every thunk table it considers is too far > away from the address it wants to branch from. Every invocation of > search_thunk_slot thus takes an early return and cannot create a thunk > entry in any of them. I had a brief chat with kangaroo on IRC about this. He suggested, if I understood correctly, that the problem might be that the code currently being patched by arm_patch_general isn't the branch instruction that we expect. However, the more I think about it the more sure I am that I didn't understand what he meant. When I look at where the failure is occurring, the value of (*code) to be patched is 0xeb0000000, which I believe is a BL instruction - branch and link. I think this is what is expected, no? With judicious use of printf, I have determined that just before this code fails, new_codechunk in mono-codeman.c has allocated a code chunk with size=4096, bsize=32, at an address that might be, for example, 0x53b15038. This is quite a big jump from the previous address returned. Shortly thereafter, handle_thunk starts searching for a thunk slot for a call from this code block (in this example, the code pointer points to 0x53b150dc, squarely inside the recently allocated code chunk). However, it seems that when handle_thunk calls mono_domain_code_foreach, it is searching a different code manager's chunk list from the one we're currently emitting code into. Is this expected? Is there one code manager for normal code in a domain and then a bunch of extra ones for dynamically emitted code? This means that the thunk table allocated with the code chunk which we're emitting into has never been considered as a location for the thunk. Since this code chunk has, by the whim of malloc, been allocated miles away from all the others, it is out of range of all the thunk tables that are considered. I'm next going to try see if I can reproduce this by doing a lot of native mallocs instead of starting up my unwieldy native library. Is there any point in filing a bug before I have a reliable reproduction, or will it just get closed WORKSFORME? Regards, Weeble. _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list