## roslyn SIGSEGV on big endian PPC machine

_Submitted by Marek Safar \[MSFT\] on 2017-03-09 14:20 UTC_

Thread 1 "mono" received signal SIGSEGV, Segmentation fault.
0x0000000010107474 in get\_generic\_context\_from\_stack\_frame (ji=0x10b444c0, generic\_info=0x10000ffff) at mini-exceptions.c:709
709			klass = vtable-\>klass;
(gdb) p vtable
$1 = (MonoVTable \*) 0x10000ffff
(gdb) p \*vtable
Cannot access memory at address 0x10000ffff
(gdb) bt
\#0  0x0000000010107474 in get\_generic\_context\_from\_stack\_frame (ji=0x10b444c0, generic\_info=0x10000ffff) at mini-exceptions.c:709
\#1  0x00000000101076fc in get\_method\_from\_stack\_frame (ji=0x10b444c0, generic\_info=0x10000ffff) at mini-exceptions.c:744
\#2  0x0000000010107c60 in ves\_icall\_get\_trace (exc=0x3fffb7017d00, skip=0, need\_file\_info=1 '\\001') at mini-exceptions.c:844
\#3  0x00003fffb758c594 in ?? ()
\#4  0x00003fffb758c260 in ?? ()
\#5  0x00003fffb758c1b4 in ?? ()
\#6  0x00003fffb758c08c in ?? ()
\#7  0x00003fffb758bf24 in ?? ()
\#8  0x00003fffb758b624 in ?? ()
\#9  0x00003fffb758b100 in ?? ()
\#10 0x00003fffb758b20c in ?? ()
\#11 0x000000001001cbc0 in mono\_jit\_runtime\_invoke (method=0x3fffffffb108, obj=0x105fa0a0, params=0x105b0828, exc=0x3fffffffae40, error=0x10654690)
```
    at mini-runtime.c:2535
```

\#12 0x000000001064af50 in ?? ()
\#13 0x00000000105b7900 in private\_handles ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

* * *

_Xamarin Bugzilla comment 1 by Zoltan Varga [MSFT] on 2017-03-09 20:45 UTC_

Please include some reproduction instructions, system configuration etc.

* * *

_Xamarin Bugzilla comment 2 by Marek Safar [MSFT] on 2017-03-10 10:58 UTC_

Zoltan, I can give you access to the machine.

Or you can reproduce it yourself by building <https://github.com/mono/mono/pull/4436> on big endian machine

* * *

_Xamarin Bugzilla comment 3 by Zoltan Varga [MSFT] on 2017-03-15 09:07 UTC_

This seems to be caused by a roslyn method being too large on ppc.

A workaround is:

diff --git a/mono/mini/mini-ppc.c b/mono/mini/mini-ppc.c
index 4af328d..95af784 100644
\--- a/mono/mini/mini-ppc.c
+++ b/mono/mini/mini-ppc.c
@@ -2031,7 +2031,7 @@ if (0 && ins-\>inst\_true\_bb-\>native\_offset) { \\
```
        ppc_bc (code, (b0), (b1), (code - cfg->native_code + ins->inst_true_bb->native_offset) & 0xffff); \
 } else { \
        int br_disp = ins->inst_true_bb->max_offset - offset;   \
```

\-       if (!ppc\_is\_imm16 (br\_disp + 1024) \|\| ! ppc\_is\_imm16 (ppc\_is\_imm16 (br\_disp - 1024))) { \\
+       if (!strcmp (cfg-\>method-\>name, "Parse") \|\| !ppc\_is\_imm16 (br\_disp + 1024) \|\| ! ppc\_is\_imm16 (ppc\_is\_imm16 (br\_disp - 1024))) { \\
```
                MonoOvfJump *ovfj = mono_mempool_alloc (cfg->mempool, sizeof (MonoOvfJump));    \
                ovfj->data.bb = ins->inst_true_bb;      \
                ovfj->ip_offset = 0;    \
```


* * *

_Xamarin Bugzilla comment 4 by Zoltan Varga [MSFT] on 2017-03-15 09:07 UTC_

I.e. the large method exposes a bug in the ppc jit.

* * *

<br />

_Reference: <https://bugzilla.xamarin.com/show_bug.cgi?id=53192>_