Bug 1704847
| Summary: | Crash on System.Linq.Enumerable+Concat2Iterator<char>.ToArray() | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | flibitijibibo | ||||
| Component: | mono | Assignee: | Timotheus Pokorra <mailinglists> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 30 | CC: | bubexel, chkr, itamar, john.j5live, knocte, lxtnow, mailinglists, rhughes, rstrode, sandmann | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-05-28 05:43:01 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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 |
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.