Created attachment 1560358 [details] Test Program Description of problem: Attempting to run Fedora's MonoDevelop package will result in the Mono runtime silently burning a CPU core, eventually ending with a NullReferenceException deep within System.Linq.Enumerable.ToArray. The root cause appears to be something within the runtime's System.Linq implementation. Version-Release number of selected component (if applicable): mono 5.18.1-2, monodevelop 5.10.0-14 How reproducible: 100% Steps to Reproduce: 1. Run /usr/bin/monodevelop in a terminal 2. Wait (this takes a while...) 3. Fatal Exception printed to terminal, program exits Actual results: MonoDevelop silently fails to load Expected results: MonoDevelop loads, presents home screen Additional info: This is reproducible with an isolated test program that replicates what MonoDevelop 5.10's FilePath static constructor does (see attached). The Concat operation succeeds, but ToArray will fail every time.
Thank you for the detailed analysis of this issue! I was able to reproduce your test case with the Fedora Mono packages. I tried with upstream mono 5.20, and that works fine. Now I need to find out, if upstream fixed something relevant for Mono 5.20, or if it is indeed a packaging issue. I will report back when I find a solution. In general, MonoDevelop needs a lot of love to get updated in Fedora. Xamarin/Microsoft are now building rpm packages again, after trying flathub packages for a while. Still there are a lot of unsatisfied dependencies for MonoDevelop 7 in Fedora. But that is a different topic.
If it narrows anything down, I was able to run the test program successfully with my last MonoKickstart build, which is based on 5.18.0.268: https://github.com/flibitijibibo/MonoKickstart And no worries on MonoDevelop - I tried to build from source and it didn't take long for me to run away screaming...
This is the commit that fixes the ToArray problem: https://github.com/mono/corefx/commit/0bf46dbe2cf0a215ca6e64793b7c434433f50722 I am applying it to Rawhide now, and will soon get it into F30 as well.
*** Bug 1708391 has been marked as a duplicate of this bug. ***
Updating to the latest package via --advisory=FEDORA-2019-9a441daf3c resolves the issue for me!
(In reply to flibitijibibo from comment #5) > Updating to the latest package via --advisory=FEDORA-2019-9a441daf3c > resolves the issue for me! Ye! it works, i had to disable the MSBuild build engine because was causing errors on the projects.- Thank you, Ethan Lee, nice to see you here around. Fan of your work since FNA :P It could be closed.
> This is the commit that fixes the ToArray problem: Hey Timotheus, that commit is in corefx, I assume that this was a submodule that mono repo pulls? Or are you talking about a bugfix of .NETCore?
Hello Andrés, this is the patch we are talking about: https://src.fedoraproject.org/rpms/mono/blob/master/f/mono-5.18.0-largearraybuilder.patch Mono 5 has some .NET Core assemblies that are part of the tarball. The patched file is in the Mono tarball at external/corefx/src/Common/src/System/Collections/Generic/LargeArrayBuilder.c Timotheus
And by any chance you have the commit id that updates the .NET Core assemblies (corefx submodule)?
Looking at https://github.com/dotnet/corefx/commits/master/src/Common/src/System/Collections/Generic/LargeArrayBuilder.cs, I cannot find a version that uses CopyToCore(buffer, column, array, arrayIndex, count) or CopyToCore(buffer, column, array, ref arrayIndex, ref count). I have no idea. Perhaps best to ask Marek directly. His E-Mail address is in the patch at https://src.fedoraproject.org/rpms/mono/blob/master/f/mono-5.18.0-largearraybuilder.patch