[Mono-dev] JIT compiler crashes application

Andrii Nakryiko andrii.nakryiko at gmail.com
Wed Dec 12 10:06:27 UTC 2012


Hi guys,

I've created a project that reliably reproduces 2 bugs, the mentioned JIT
crash, and just plain segmentation fault even without stack traces:
https://github.com/anakryiko/mono-jit-crash-repro

>From readme:

mono-jit-crash-repro
====================

Reproduction of problems with Mono JIT crashing.

To run reproduce, compile the solution and run **run.sh** script which will
start the binary in a loop until the program crashes. It usually doesn't
take long for crash or segmentation fault to occur, though it can take up
to few thousands runs.

There are two classes that reproduces two bugs:

  * **ReproJitCrash.cs** reproduces JIT crash most of the times. Rarely it
also causes segmentation fault without any stack traces.
  * **ReproSegFault.cs** reproduces segmenation fault with no stack trace
(as mentioned previously).

The only difference between those two cases is in using *struct* vs *class*
with **using** statement (see LockReleaserStruct/LockReleaserClass).

Also, it seems essential to have Monitor.Enter/Monitor.Exit, without them
it's not reproducible (or at least I didn't have patience to wait for crash
to happen).

Hope that helps to identify and fix the problem.

-- Andrii Nakryiko

-- Andrii Nakryiko



2012/12/6 Rodrigo Kumpera <kumpera at gmail.com>

>
>
>
> On Thu, Dec 6, 2012 at 12:38 PM, Andrii Nakryiko <
> andrii.nakryiko at gmail.com> wrote:
>
>> It's not about that particular method, we got earlier same kind of
>> crashes on different methods, for
>> instance, ProtoBuf.Serializers.ArrayDecorator:Write ()
>> If I remember correctly, I got this crash even for some method on
>> List<T>, though I can't locate that log quickly. If I get it, will post
>> here.
>> Also, this bug manifests on different versions of Mono (< 3.0).
>>
>
> So the problem is not miscompilation. It might be memory corruption
> related. Can you try running it under valgrind or any other malloc debug
> tools?
> Does it always crash on that particular g_assert? If it does, it's a
> matter of augmenting it to produce a better crash message.
>
>
>
>
>
>> This behavior is very randomly reproducible. To give you some context, we
>> constantly run "test scenarios" where we start our TestClient in a loop.
>> TestClient does some work and then exits. Then our shell script starts
>> TestClient again. And sometimes TestClient crashes with error I described.
>> What is interesting, crash mostly occurs not on first run of TestClient
>> during this test scenario. Maybe that can help somehow.
>>
>
> Then please try to reduce it to a test case that is small enough so we can
> work on.
>
> Can using LLVM back-end help to mitigate this?
>>
>
>
> I have no reason to believe that the LLVM backend would help here.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20121212/1683a40d/attachment.html>


More information about the Mono-devel-list mailing list