Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mono fails to build on FreeBSD/PowerPC64 #11021

Closed
lenoil98 opened this issue Oct 7, 2018 · 27 comments

Comments

@lenoil98
Copy link

@lenoil98 lenoil98 commented Oct 7, 2018

I understand that PowerPC64 is not officially supported on FreeBSD. I can successfully build 32-bit Mono on FreeBSD/PowerPC. The 64-bit build progresses fairly well. However I get a SIGILL when building. Below is an excerpt from the build log:

System.Net/HttpConnection.cs(57,19): warning CS0414: The private field `System.Net.HttpConnection.cert' is assigned but its value is never used
System.Net/HttpWebRequest.cs(86,10): warning CS0414: The private field `System.Net.HttpWebRequest.initialMethod' is assigned but its value is never used
System.Net/WebConnection.cs(196,25): warning CS0649: Field `System.Net.WebConnection.ID' is never assigned to, and will always have its default value `0'
System.Net/WebConnectionStream.cs(46,10): warning CS0414: The private field `System.Net.WebConnectionStream.locker' is assigned but its value is never used
System.Net/WebConnectionStream.cs(49,17): warning CS0649: Field `System.Net.WebConnectionStream.IgnoreIOErrors' is never assigned to, and will always have its default value `false'
System.Net/WebOperation.cs(65,25): warning CS0649: Field `System.Net.WebOperation.ID' is never assigned to, and will always have its default value `0'
System.Net/WebOperation.cs(66,10): warning CS0649: Field `System.Net.WebOperation.ME' is never assigned to, and will always have its default value `null'
System.Net/WebRequestStream.cs(49,28): warning CS0649: Field `System.Net.WebRequestStream.ME' is never assigned to, and will always have its default value `null'
System.Net/WebResponseStream.cs(78,28): warning CS0649: Field `System.Net.WebResponseStream.ME' is never assigned to, and will always have its default value `null'
Compilation succeeded - 45 warning(s)
MCS     [basic] System.Xml.dll
MCS     [basic] System.Security.dll
../../../external/corefx/src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/KeyInfoRetrievalMethod.cs(78,24): warning CS0219: The variable `retrievalMethodElement' is assigned but its value is never used
System.Security.Cryptography.Xml/SignedXml.cs(391,11): warning CS0219: The variable `hashvalue' is assigned but its value is never used
Compilation succeeded - 2 warning(s)
MCS     [basic] System.Core.dll
../../build/common/MonoTODOAttribute.cs(100,25): warning CS1635: Cannot restore warning `CS0436' because it was disabled globally
../../../external/corefx/src/System.Security.Cryptography.Algorithms/src/System/Security/Cryptography/IncrementalHash.net46.cs(23,26): warning CS0472: The result of comparing value type `System.Security.Cryptography.HashAlgorithmName' with null is always `true'
Compilation succeeded - 2 warning(s)
MCS     [basic] System.ComponentModel.Composition.dll
MCS     [basic] System.Numerics.dll
MCS     [basic] System.Xml.Linq.dll
MCS     [basic] Mono.Cecil.dll
MCS     [basic] Mono.Cecil.Mdb.dll
MCS     [basic] Mono.CompilerServices.SymbolWriter.dll
MCS     [basic] PEAPI.dll
mkdir -p -- ../../class/lib/basic/tmp/
MCS     [basic] cil-stringreplacer.exe
./../jay/jay: 7 rules never reduced
./../jay/jay: 14 shift/reduce conflicts.
MCS     [basic] ilasm.exe
ILParser.cs(165,37): warning CS0429: Unreachable expression code detected
ILParser.cs(165,68): warning CS0429: Unreachable expression code detected
ILParser.cs(166,7): warning CS0162: Unreachable code detected
codegen/CodeGen.cs(460,48): warning CS0219: The variable `asmb' is assigned but its value is never used
codegen/DebuggingInfo.cs(103,16): warning CS0219: The variable `entry' is assigned but its value is never used
codegen/PeapiTypeRef.cs(249,25): warning CS0162: Unreachable code detected
codegen/CodeGen.cs(60,30): warning CS0414: The private field `Mono.ILASM.CodeGen.image_base' is assigned but its value is never used
codegen/MethodDef.cs(54,33): warning CS0414: The private field `Mono.ILASM.MethodDef.codegen' is assigned but its value is never used
codegen/DataDef.cs(18,43): warning CS0414: The private field `Mono.ILASM.DataDef.segment' is assigned but its value is never used
Compilation succeeded - 9 warning(s)
Assembling '../../../class/corlib/System.Runtime.CompilerServices/Unsafe.il' , no listing file, to dll --> '../../../class/lib/basic/corlib.unsafe.dll.tmp'

../../../class/corlib/System.Runtime.CompilerServices/Unsafe.il : Warning -- Reference to undeclared extern assembly 'mscorlib', adding.
Operation completed successfully
mkdir -p -- ../../../class/lib/basic/Facades/
./../jay/jay: 7 shift/reduce conflicts.
MCS     [basic] System.Runtime.dll
MCS     [basic] System.Collections.dll
MCS     [basic] System.Reflection.dll
MCS     [basic] mcs.exe
MCS     [basic] System.Resources.ResourceManager.dll
MCS     [basic] System.Globalization.dll
MCS     [basic] System.Threading.Tasks.dll
MCS     [basic] System.Collections.Concurrent.dll
MCS     [basic] System.Text.Encoding.dll
MCS     [basic] System.IO.dll
MCS     [basic] System.Threading.dll
MCS     [basic] System.Diagnostics.Debug.dll
MCS     [basic] System.Linq.Expressions.dll
MCS     [basic] System.Dynamic.Runtime.dll
MCS     [basic] System.Linq.dll
MCS     [basic] System.Threading.Tasks.Parallel.dll
MCS     [basic] System.Xml.ReaderWriter.dll
MCS     [basic] System.Diagnostics.Tools.dll
MCS     [basic] System.Reflection.Primitives.dll
MCS     [basic] System.Runtime.Extensions.dll
MCS     [basic] System.Runtime.InteropServices.dll
MCS     [basic] System.Text.Encoding.Extensions.dll
MCS     [basic] System.Runtime.Numerics.dll
MCS     [basic] System.Xml.XDocument.dll
MCS     [basic] System.Reflection.Extensions.dll
MCS     [basic] System.IO.FileSystem.Primitives.dll
MCS     [basic] System.IO.FileSystem.dll
MCS     [basic] System.Diagnostics.FileVersionInfo.dll
MCS     [basic] System.Security.Cryptography.Primitives.dll
MCS     [basic] System.Security.Cryptography.Algorithms.dll
MCS     [basic] System.ValueTuple.dll
MCS     [basic] System.Text.Encoding.CodePages.dll
Creating .dep_dirs-build...
Creating .dep_dirs-build...
mkdir -p -- ../../class/lib/build-linux/
Stacktrace:

  at <unknown> <0xffffffff>
  at System.Globalization.CultureData.get_Invariant () [0x000b2] in <445343b3499f4493aad682c3d706c4c0>:0
  at <unknown> <0xffffffff>
  at Mono.ILASM.Driver.Main (string[]) [0x00005] in <cab757a6a332478ea5d0afa123379e6b>:0
  at (wrapper runtime-invoke) <Module>.runtime_invoke_int_object (object,intptr,intptr,intptr) [0x00054] in <cab757a6a332478ea5d0afa123379e6b>:0

=================================================================
Got a SIGILL while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

gmake[10]: *** [il/il.make:4: ../../class/lib/build-linux/corlib.unsafe.dll.tmp] Abort trap (core dumped)
gmake[10]: *** Waiting for unfinished jobs....
gmake[9]: *** [../../build/rules.make:211: do-all] Error 2
gmake[8]: *** [../build/rules.make:232: all-recursive] Error 1
gmake[7]: *** [build/rules.make:232: all-recursive] Error 1
gmake[6]: *** [Makefile:54: profile-do--build--all] Error 2
gmake[5]: *** [Makefile:50: profiles-do--all] Error 2
gmake[4]: *** [Makefile:610: all-local] Error 2
gmake[4]: Leaving directory '/usr/ports/lang/mono/work/mono-5.14.0.177/runtime'
gmake[3]: *** [Makefile:552: all-recursive] Error 1
gmake[3]: Leaving directory '/usr/ports/lang/mono/work/mono-5.14.0.177'
gmake[2]: *** [Makefile:482: all] Error 2
gmake[2]: Leaving directory '/usr/ports/lang/mono/work/mono-5.14.0.177'
===> Compilation failed unexpectedly.

Anyone with suggestions will be greatly appreciated.

@lewurm lewurm added the target-ppc64 label Oct 8, 2018
@lewurm

This comment has been minimized.

Copy link
Member

@lewurm lewurm commented Oct 8, 2018

@lenoil98 thanks for your report. could you specify which version/revision of mono you are trying to build? also, could you make sure gdb is installed? with that mono should provide a better native stack trace.

@NattyNarwhal

This comment has been minimized.

Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Oct 8, 2018

I think I vaguely remember this happening under AIX - I can't remember if it was a case of bad hwcap (FreeBSD has no implementation at all for PowerPC) or when I was trying to get PPC32 to work (some kind of fucky calling convention issue) - if I recall, this icall is called early and has a strange calling convention layout that stresses marshalling (I think floats?)

@NattyNarwhal

This comment has been minimized.

Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Oct 8, 2018

Oh, I was misremembering, I'm pretty sure it was the time I tried to get Darwin/ppc working again.

@lenoil98

This comment has been minimized.

Copy link
Author

@lenoil98 lenoil98 commented Oct 8, 2018

Build is against Mono-5.14.0.177. gdb is installed but debugging not enabled, will rerun build with debugging enabled.

@NattyNarwhal

This comment has been minimized.

Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Oct 8, 2018

for ppc64 I'd recommend building against the latest git master; if I remember correctly, there's been some improvements there. (I also verified master DOES build with FreeBSD/amd64 OOTB.)

also, if FreeBSD for ppc64 works on IBM systems, let me know; I might be able to get an LPAR to try myself on with.

@NattyNarwhal

This comment has been minimized.

Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Oct 8, 2018

Actually, my suspicion here is that the calling convention definitions for FreeBSD are wrong; either by differing from Linux, or by using the wrong definitions. I'm very sure this is the first icall called, so it makes sense that it has issues.

What calling conventions does FreeBSD on ppc64 use? Do they match up with the ifdefs in mini-ppc.*? Can we get a FreeBSD/powerpc developer here to clarify?

@lenoil98

This comment has been minimized.

Copy link
Author

@lenoil98 lenoil98 commented Oct 9, 2018

Could this be an ENDIAN issue. I noticed there are a few tests for "_CALL_ELF == 2" in the ppc code. This makes me believe the ppc 64bit code is written for the ppc64le. Does anyone know if mono builds on BE ppc64 Linux OOTB?

@NattyNarwhal

This comment has been minimized.

Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Oct 9, 2018

the _CALL_ELF stuff is indeed for Linux - the way its set up, is that ppc64 with ELFv1 calling convention (most ppc64be Linux and AIX/PASE via a historical quirk) will build with the ELFv1 ABIs when its not present or set to 1, and ppc64 with the ELFv2 calling convention (ppc64le Linux and some ppc64be Linux, particularly distros that use musl) will build with the ELFv2 ABIs with it set to 2.

I think FreeBSD actually uses the ELFv2 one on ppc64 too, so I wonder what defines it uses. Can you paste the output of echo | cc -dM -E? (replace cc with gcc if needed)

@awilfox

This comment has been minimized.

Copy link

@awilfox awilfox commented Oct 9, 2018

FreeBSD uses "whatever ABI the compiler supports". For gcc 4.2, that's ELFv1; for LLVM, it could be either one, and indeed, there have been "test" images using ELFv2 on FreeBSD BE.

GCC has always provided _CALL_ELF since adding ELFv2 support, and that macro being defined is required for any C compiler that implements ELFv2. Therefore, you are guaranteed to have either no _CALL_ELF if ELFv1 ABI is in use or _CALL_ELF defined to something if the toolchain is new enough to support ELFv2.

@NattyNarwhal

This comment has been minimized.

Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Oct 9, 2018

Yeah, I haven't tested Mono on a ppc64be system with ELFv2; just ELFv1 BE Linux and AIX/i. For all I know, there could be some incorrect ifdef; there has been before.

@lenoil98

This comment has been minimized.

Copy link
Author

@lenoil98 lenoil98 commented Oct 11, 2018

I checked with Justin Hibbits and here are his thoughts:

I get the sneaking suspicion with ABI issues. A SIGILL likely means,
if you can track it down in a debugger, that it's calling a function
descriptor as a function. Since I haven't even bothered to look at any
code yet, it's purely a guess, but I'm guessing they're targeting ELFv2
these days (particularly, ppc64le primarily), and ELFv1 has
languished. ELFv1 requires function descriptors, whereas ELFv2 does
not. If the compiler doesn't know that it has to call through the
function descriptor, which is an indirect call, then it could be
calling the function descriptor itself instead of the function it
describes.

@NattyNarwhal

This comment has been minimized.

Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Oct 11, 2018

I was trying to get his attention on IRC, but he didn't respond back. Mono does support ELFv2 (the CI builder is ppc64le, so ELFv2) but it still does support the ELFv1 ABI with function descriptors; AIX is using (something to close to, at least) said ABI., and that's run over CI.

I did have similar issues with bringup on AIX, (trying to make it use function descriptors; see #6677 for what that entailed) but the fact you're hitting the issue on what I believe to be the first icall (meaning trampolines generated for the first managed function ran, the OutOfMemoryException ctor, worked out enough to get this far) means it might be a bit pickier.

@lewurm

This comment has been minimized.

Copy link
Member

@lewurm lewurm commented Oct 11, 2018

it also could be that mono is emitting an instruction that isn't understood by your hardware; what CPU are you running on? (although it's likely the mentioned ABI mismatch).

@lenoil98

This comment has been minimized.

Copy link
Author

@lenoil98 lenoil98 commented Oct 11, 2018

I'm running on PowerPC 970MP (Dual Core). Everything I've read is only supports ELFv1 on this processor.

@awilfox

This comment has been minimized.

Copy link

@awilfox awilfox commented Oct 11, 2018

It has nothing to do with the processor. ELFv2 works fine on the 970MP, in an environment that uses ELFv2. There are no newer instructions needed for that calling convention. The Linux musl libc, for example, uses ELFv2 all the way back to the POWER4.

That said, you should make sure that it is being compiled with -mcpu=970 or similar, so that GCC isn't emitting newer instructions.

@NattyNarwhal

This comment has been minimized.

Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Oct 11, 2018

Well, the Mono JIT could be emitting the invalid opcodes in this case. There is no hwcap for FreeBSD/ppc64, so it'll use a very conservative set of instructions. (no POWER4 instructions, no PPC64 instructions, no POWER7 instructions, no load/store optimizations - maybe it needs one of them on ppc64?)

@lenoil98

This comment has been minimized.

Copy link
Author

@lenoil98 lenoil98 commented Oct 11, 2018

Let me clarify, I meant that FreeBSD only supports ELFv1 on PowerPC. Being that this is a Tier 2 supported platform and does not always get some updated features.

BTW, I tried compiling with -mcpu970 and got the same results.

@NattyNarwhal

This comment has been minimized.

Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Oct 11, 2018

Unfortunately, we're kinda flying blind here unless we have a disassembly - if you have objdump installed, run mono with -v -v.

One thing I realized just now is.... basic profile builds fine with what I assume is Monolite, but the build goes nuts once it changes over to the platform-specific build profile. I want to get my hands on a FreeBSD/powerpc64 system for myself and try to poke it; I'll see if I can't poke some people for an LPAR if it runs on pSeries...

@lenoil98

This comment has been minimized.

Copy link
Author

@lenoil98 lenoil98 commented Oct 12, 2018

Here the output for mono -v -V:

Mono JIT compiler version 5.14.0.177 (5.14.0.177 Thu Oct 11 22:10:44 UTC 2018)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notification: kqueue
Architecture: ppc
Disabled: none
Misc: softdebug
Interpreter: yes
GC: sgen (concurrent by default)

@NattyNarwhal

This comment has been minimized.

Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Oct 12, 2018

-v -v needs to be run with the program. You can monkey patch runtime/mono-wrapper to include it; alternatively, you can also edit said file to run Mono under gdb (like gdb --args the mono executable...)

@lenoil98

This comment has been minimized.

Copy link
Author

@lenoil98 lenoil98 commented Oct 12, 2018

Okay, the output the attached.

mono.log

@awilfox

This comment has been minimized.

Copy link

@awilfox awilfox commented Oct 12, 2018

  ec:   00 00 01 01     .long 0x101
  f0:   00 00 01 01     .long 0x101

That looks wrong.

@lewurm

This comment has been minimized.

Copy link
Member

@lewurm lewurm commented Oct 12, 2018

That's indeed wrong.

  ec:	00 00 01 01 	.long 0x101
  f0:	00 00 01 01 	.long 0x101
  f4:	78 00 07 c6 	rldicr  r0,r0,32,31
  f8:	50 92 01 01 	rlwimi. r18,r4,0,4,0
  fc:	59 dc 01 01 	rlmi.   r28,r14,r0,4,0

is generated by this:

mono/mono/mini/mini-ppc.c

Lines 5290 to 5292 in 51ebea7

#ifdef __mono_ppc64__
ppc_load_sequence (code, ppc_r0, (guint64)0x0101010101010101LL);
#else

which expands to:
#ifdef __mono_ppc64__
#define ppc_load_sequence(c,D,v) G_STMT_START { \
ppc_lis ((c), (D), ((guint64)(v) >> 48) & 0xffff); \
ppc_ori ((c), (D), (D), ((guint64)(v) >> 32) & 0xffff); \
ppc_sldi ((c), (D), (D), 32); \
ppc_oris ((c), (D), (D), ((guint64)(v) >> 16) & 0xffff); \
ppc_ori ((c), (D), (D), (guint64)(v) & 0xffff); \
} G_STMT_END

Later this code will be patched by

mono/mono/mini/mini-ppc.c

Lines 4718 to 4721 in 51ebea7

switch (ji->type) {
case MONO_PATCH_INFO_IP:
patch_load_sequence (ip, ip);
break;

mono/mono/mini/mini-ppc.c

Lines 4691 to 4699 in 51ebea7

#elif defined _BIG_ENDIAN
#define patch_load_sequence(ip,val) do {\
guint16 *__load = (guint16*)(ip); \
g_assert (sizeof (val) == sizeof (gsize)); \
__load [1] = (((guint64)(gsize)(val)) >> 48) & 0xffff; \
__load [3] = (((guint64)(gsize)(val)) >> 32) & 0xffff; \
__load [7] = (((guint64)(gsize)(val)) >> 16) & 0xffff; \
__load [9] = ((guint64)(gsize)(val)) & 0xffff; \
} while (0)

so...

Method [...] emitted at 0x509258f0 to 0x50925b04 (code length 532) [ilasm.exe]

therefore the address that should be patched in is 0x509258f0 + 0xec = 0x509259dc. Have a look again at the disassembly, can you spot those values? 😉 Note it's really 0x0000_0000_5092_59dc that we patch in.

Not sure what goes wrong here. Wrong macro maybe? _LITTLE_ENDIAN/_BIG_ENDIAN is used for defining patch_load_sequence (), but usually we have G_LITTLE_ENDIAN/G_BIG_ENDIAN in mono. Could you give that a try @lenoil98 ?

edit: as @NattyNarwhal pointed out, it should be something like

#elif G_BYTE_ORDER == G_BIG_ENDIAN
@NattyNarwhal

This comment has been minimized.

Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Oct 12, 2018

A lot of the PPC ABI sensitive things are (IMHO) guarded by the wrong the definitions - ones that might work on glibc Linux, but got sketchy anywhere else. (The obvious ones had to be fixed for AIX, for instance.) This one on mini-ppc.c+4691 looks sketchy even if you changed it to G_BYTE_ORDER; should be _CALL_ELF != 2 or at the least, or be G_BYTE_ORDER == G_BIG_ENDIAN. (The latter is what I had to do to fix the previous decimal impl....)

@lenoil98

This comment has been minimized.

Copy link
Author

@lenoil98 lenoil98 commented Oct 12, 2018

Changing line 4691 as suggested you suggested did the trick. Changed line 4682, for consistency, to

#if G_BYTE_ORDER == G_LITTLE_ENDIAN

@NattyNarwhal

This comment has been minimized.

Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Oct 12, 2018

Nice! Could you submit a PR/patch for it here? I'm curious what it does to Linux/ppc64le and aix/ppc64be in this case.

@NattyNarwhal

This comment has been minimized.

Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Oct 12, 2018

I can file a properly branched PR for you over my lunch break after I test it on AIX, hold still...

lewurm added a commit to lewurm/mono that referenced this issue Oct 12, 2018
NattyNarwhal added a commit to NattyNarwhal/mono that referenced this issue Oct 12, 2018
Integrate these PRs that aren't branched properly:

	* Trampoline patching ifdefs were wrong. (mono#11125)

	* ucontext macros are wrong for this platform (mono#11020)

Tested on AIX, doesn't seem to regress there. I haven't myself
tested this on FreeBSD or Linux though.

Fixes mono#11021. Thanks to @lenoil98 for reporting and fixing these.
monojenkins added a commit that referenced this issue Oct 15, 2018
[ppc] use G_BYTE_ORDER in order to define patch_load_sequence

Fixes #11021
alexanderkyte added a commit to alexanderkyte/mono that referenced this issue Oct 17, 2018
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Apr 24, 2019
Bumps to mono/api-snapshot@ae01378
Bumps to mono/reference-assemblies@e5173a5
Bumps to mono/bockbuild@d30329d
Bumps to mono/boringssl@3d87996
Bumps to mono/corefx@72f7d76
Bumps to mono/corert@1b7d4a1
Bumps to mono/helix-binaries@7e893ea
Bumps to mono/illinker-test-assets@f21ff68
Bumps to mono/linker@13d864e
Bumps to mono/llvm@1aaaaa5 [mono]
Bumps to mono/llvm@2c2cffe [xamarin-android]
Bumps to mono/NUnitLite@0029561
Bumps to mono/roslyn-binaries@0bbc9b4
Bumps to mono/xunit-binaries@8f6e62e

	$ git diff --shortstat 886c4901..e66c7667      # mono
        3597 files changed, 350850 insertions(+), 91128 deletions(-)
	$ git diff --shortstat 349752c464c5fc93b32e7d45825f2890c85c8b7d..2c2cffedf01e0fe266b9aaad2c2563e05b750ff4
	 240 files changed, 18562 insertions(+), 6581 deletions(-)

Context: dotnet/coreclr#22046

Fixes: CVE 2018-8292 on macOS
Fixes: http://work.devdiv.io/737323
Fixes: dotnet/corefx#33965
Fixes: dotnet/standard#642
Fixes: mono/mono#6997
Fixes: mono/mono#7326
Fixes: mono/mono#7517
Fixes: mono/mono#7750
Fixes: mono/mono#7859
Fixes: mono/mono#8360
Fixes: mono/mono#8460
Fixes: mono/mono#8766
Fixes: mono/mono#8922
Fixes: mono/mono#9418
Fixes: mono/mono#9507
Fixes: mono/mono#9951
Fixes: mono/mono#10024
Fixes: mono/mono#10030
Fixes: mono/mono#10038
Fixes: mono/mono#10448
Fixes: mono/mono#10735
Fixes: mono/mono#10735
Fixes: mono/mono#10737
Fixes: mono/mono#10743
Fixes: mono/mono#10834
Fixes: mono/mono#10837
Fixes: mono/mono#10838
Fixes: mono/mono#10863
Fixes: mono/mono#10945
Fixes: mono/mono#11020
Fixes: mono/mono#11021
Fixes: mono/mono#11021
Fixes: mono/mono#11049
Fixes: mono/mono#11091
Fixes: mono/mono#11095
Fixes: mono/mono#11123
Fixes: mono/mono#11138
Fixes: mono/mono#11146
Fixes: mono/mono#11202
Fixes: mono/mono#11214
Fixes: mono/mono#11317
Fixes: mono/mono#11326
Fixes: mono/mono#11378
Fixes: mono/mono#11385
Fixes: mono/mono#11478
Fixes: mono/mono#11479
Fixes: mono/mono#11488
Fixes: mono/mono#11489
Fixes: mono/mono#11527
Fixes: mono/mono#11529
Fixes: mono/mono#11596
Fixes: mono/mono#11603
Fixes: mono/mono#11613
Fixes: mono/mono#11623
Fixes: mono/mono#11663
Fixes: mono/mono#11681
Fixes: mono/mono#11684
Fixes: mono/mono#11693
Fixes: mono/mono#11697
Fixes: mono/mono#11779
Fixes: mono/mono#11809
Fixes: mono/mono#11858
Fixes: mono/mono#11895
Fixes: mono/mono#11898
Fixes: mono/mono#11898
Fixes: mono/mono#11965
Fixes: mono/mono#12182
Fixes: mono/mono#12193
Fixes: mono/mono#12218
Fixes: mono/mono#12235
Fixes: mono/mono#12263
Fixes: mono/mono#12307
Fixes: mono/mono#12331
Fixes: mono/mono#12362
Fixes: mono/mono#12374
Fixes: mono/mono#12402
Fixes: mono/mono#12421
Fixes: mono/mono#12461
Fixes: mono/mono#12479
Fixes: mono/mono#12479
Fixes: mono/mono#12552
Fixes: mono/mono#12603
Fixes: mono/mono#12747
Fixes: mono/mono#12831
Fixes: mono/mono#12843
Fixes: mono/mono#12881
Fixes: mono/mono#13030
Fixes: mono/mono#13284
Fixes: mono/mono#13297
Fixes: mono/mono#13455
Fixes: mono/mono#13460
Fixes: mono/mono#13478
Fixes: mono/mono#13479
Fixes: mono/mono#13522
Fixes: mono/mono#13607
Fixes: mono/mono#13610
Fixes: mono/mono#13610
Fixes: mono/mono#13639
Fixes: mono/mono#13672
Fixes: mono/mono#13834
Fixes: mono/mono#13878
Fixes: mono/mono#6352
Fixes: mono/monodevelop#6898
Fixes: xamarin/maccore#1069
Fixes: xamarin/maccore#1407
Fixes: xamarin/maccore#604
Fixes: xamarin/xamarin-macios#4984
Fixes: xamarin/xamarin-macios#5289
Fixes: xamarin/xamarin-macios#5363
Fixes: xamarin/xamarin-macios#5381
Fixes: https://issuetracker.unity3d.com/issues/editor-crashes-with-g-logv-when-entering-play-mode-with-active-flowcanvas-script
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.