[Mono-dev] Assertion failures when using Moq on Linux/ARM

[Weeble]

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 <clockworksaint at 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.