Bug 53192 - roslyn SIGSEGV on big endian PPC machine
Summary: roslyn SIGSEGV on big endian PPC machine
Status: NEW
Alias: None
Product: Runtime
Classification: Mono
Component: JIT (show other bugs)
Version: master
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Zoltan Varga
Depends on:
Reported: 2017-03-09 14:20 UTC by Marek Safar
Modified: 2017-04-10 20:23 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 53192 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Marek Safar 2017-03-09 14:20:04 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?)
Comment 1 Zoltan Varga 2017-03-09 20:45:57 UTC
Please include some reproduction instructions, system configuration etc.
Comment 2 Marek Safar 2017-03-10 10:58:01 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
Comment 3 Zoltan Varga 2017-03-15 09:07:08 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;    \
Comment 4 Zoltan Varga 2017-03-15 09:07:38 UTC
I.e. the large method exposes a bug in the ppc jit.