Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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 57962 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
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
Created attachment 23314 [details]
Log from user
1) Download https://github.com/IronLanguages/main/releases/download/ipy-2.7.7/IronPython-2.7.7-win.zip
3) mono --trace ./ipy.exe
Expected (and behavior under 4.8): an IronPython REPL will start
Actual: stackoverflow/core dump
The exact same binaries will start a REPL on 4.8, but have a stackoverflow from some weird recursive call. This is a regression in mono 5.0.
Also, see https://github.com/IronLanguages/ironpython2/issues/37 for the issue reported by a user.
I can reproduce with the information you provided. The change in Mono is we switched the System.Linq.Expressions implementation from ReferenceSource to CoreFX.
From a conversation with Alex:
> So, for this issue, the interesting thing is if I BUILD the code using
> the newer mono version, I don't see the issue, it's only if I run a
> version of IPy that was built with 4.8 that the issue arises
is that something supposed to work? Also:
> It works fine to build something on 5.x and then run under 4.8
So the other way around works.
from a conversation with Marek:
> Marek Safar [23:04]:
> @lewurm interesting, this is the first time we have this kind of issue
> it’s supported unless it’s a bug which in this case would probably have to mcs bug or some really obscure bcl hole
I can still reproduce it with Mono 5.4. Running bundled ipy (which is what we build and distribute) fails for me
$ ipy --version
Traceback (most recent call last):
TypeError: Value cannot be null.
Parameter name: method
Does mono build the latest ipy? The repository changed to IronLanguages/ironpython2 instead of IronLanguages/main, so just want to make sure that you are grabbing the correct code for distribution.
We are building it using our script at https://github.com/mono/mono/blob/master/packaging/MacSDK/ironlangs.py
That looks like an incredibly old version to me. IronRuby is no longer supported at all and there is no longer an IronPython.Mono.sln. Is this only distributed on macOS?
@Alex Earl: yes we bundle pretty ancient versions and we should update them at some point. They are only distributed on macOS.
I'll take a look at the issue, an error still happens with Mono 5.11 as mentioned in Comment 4, even with the downloaded IronPython-2.7.7-win.zip
First of all the originally reported stackoverflow/runtime crash seems to be fixed, I can't repro it anymore with Mono 5.4
Going further, in the bundled ipy wrapper script we do the following:
> export IRONPYTHONPATH=/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/
> exec /Library/Frameworks/Mono.framework/Versions/5.4.1/bin/mono /Library/Frameworks/Mono.framework/Versions/5.4.1/lib/ironpython/ipy.exe "$@"
This was done by https://github.com/mono/bockbuild/commit/f4c0f248ed6b7ef1b0c905cba69fad28aec1797a so we get access to the "os" etc modules.
If I remove the IRONPYTHONPATH env var and just run "mono /path/to/ipy.exe" then it starts the REPL normally.
I then remembered that we switched the main "mono" binary from 32bit to 64bit in Mono 5.2. Indeed if I run "mono32 ipy.exe" _with_ the IRONPYTHONPATH env var set then it starts the REPL normally, but still prints an error:
> Traceback (most recent call last):
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 62, in <module>
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py", line 49, in <module>
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py", line 17, in <module>
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/warnings.py", line 8, in <module>
> SystemError: Object reference not set to an instance of an objectIronPython 3.0 (220.127.116.11) on .NET 4.0.30319.42000
My current (unverified) assumption is that it tries to load some OS library and falls over the 32/64bit trap. A quick test using ipy64.exe resulted in the initial error from Comment 4.
Next I tried using the binaries in IronPython-2.7.7-win.zip from Comment 1. I see the same behavior there ("works" with mono32), except that IRONPYTHONPATH env var isn't set but it loads modules from the Lib/ subfolder. If I rename the folder then the REPL boots with the python traceback from before.
I assume it is the same underlying issue in both IronPython-2.7.7 and the old one we bundle in Mono. I'll try building IronPython now and step through the code :)
Make sure you use the correct repo, https://github.com/IronLanguages/ironpython2.
@Alex Earl: I'm using ipy-2.7-maint branch in https://github.com/IronLanguages/main since that seems to be where https://github.com/IronLanguages/main/releases/download/ipy-2.7.7/IronPython-2.7.7-win.zip was produced from. Do you think this would be fixed in current https://github.com/IronLanguages/ironpython2 code?
No, not necessarily, we still see some issues on the latest code, but this specific issue was about the 2.7.7 release that someone was trying to run, so the branch you specify is probably correct.
Alexander, what's the update on the progress ?
There seems to be a reasonable workaround in using the recent builds of ipy, so reducing the priority