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
interactive interpreter crashes and test_readline fails on OS X 10.9 Mavericks due to libedit update #62658
Comments
Modules/readline.c contains a workaround for a bug in the readline emulation of libedit: that emulation uses a different starting offset for the history than the real readline. In more recent versions of libedit (such as the one you can now download from <http://www.thrysoee.dk/editline/\>) the bug has been fixed and the workaround causes problems. The attached patch dynamicly detects if the workaround is necessary. NOTE: Actually using the trysoee.dk libedit requires a patch to setup.py, that version of libedit does not install libreadline.dylib, only libedit.dylib. |
(set as "crash" because the current workaround causes a crash with recent versions of libedit) |
Just wanted to chime in that I reported this to Apple and their response was exactly this. (Perhaps Ronald works for Apple?) Is there a temporary work around in the meantime other than rebuilding everything? |
If you are using an existing binary installation, you could disable readline processing altogether by simply renaming the readline extension module, for example: cd /Library/Frameworks/Python.framework/Versions/3.3 Of course, then you will not have interactive command line history and much of the editing features. But it shouldn't crash. If you don't mind using GNU readline (which is GPL licensed), you *might* be able to install the third-party readline module from PyPI: As necessary, we will likely need to provide updates for the OS X installers in conjunction with the official release of 10.9. |
Building just the readline extension shouldn't be that hard, using a small custom setup.py script. Then install by manually copying it to the right location. And no, I don't work for Apple. |
The original patch missed one spot. Here's an updated version. I'm going to apply this to default (for the imminent 3.4.0a2) in case people start running into this on new versions of OS X. It needs to be backported to 2.7 and 3.3; a test would be nice and it could be simplified a bit as part of the generalized support for libedit (bpo-13501). |
New changeset b6b8a2171aa3 by Ned Deily in branch 'default': |
New changeset 1e03fd72e116 by Ned Deily in branch '2.7': New changeset dfb7cab9f819 by Ned Deily in branch '3.3': New changeset 47a7313f079a by Ned Deily in branch 'default': |
Backported to 2.7 (for 2.7.6) and 3.3 (for 3.3.3) as well. The current test_readline already covers this case. |
I've attached a fixed readline.so built from today's 2.7 branch, for the convenience of anyone who upgraded to 10.9 and now has crashing Python. Drop the file in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload, replacing the original readline.so. This file is compatible with both 32-bit and 64-bit python.org builds of Python 2.7.5. |
Robert, I appreciate your effort but I do not think it is good practice to recommend downloading and installing binary bits from the bug tracker from an uploaded file. Also, at a cursory examination, the readline.so supplied is not exactly a drop-in replacement for the one supplied by the python.org installer as it is linked with wrong ncurses library. We should have a new set of maintenance releases soon. My preference would be for you to delete that file. |
Until the updated readline module is available in python.org 2.7.6 and 3.3.3 maintenance releases, here is a script that will check python.org versions of Python 2.7.x, 3.2.x, 3.3.x, and 3.4.x for interactive crashes and will patch around the problem as needed. On most systems you will need to run it under an account with administrator privileges. To use it, open a terminal session in Terminal.app (or other shell), then enter: curl -O http://bugs.python.org/file32324/patch_readline_issue_18458.sh The output on a 10.9 system with python.org 2.7.5, 3.3.2, and 3.4.0a4 installed should look something like this: -- running on OS X 10.9 |
Does this affect 2.6? Is there a patch we need to get into 2.6.9 final? |
Barry: yes, 2.6 is affected. See discussion on python-dev. |
On Oct 24, 2013, at 08:14 PM, Ned Deily wrote:
Thanks Ned for the background over on python-dev. Unless I hear objections |
An update: release candidates for Python 3.3.3 and 2.7.6 are now available, including binary installers for OS X, that include this fix and fully support OS X 10.9. |
I had to do After applying this patch, I got the following output, and the problem is still *not* solved for me: -- running on OS X 10.9 |
Mark, I'm not sure I understand what you saw but the patch script will cause a Python crash as part of its testing so that is to be expected. You should not have to run the script using sudo. This script also only applies to Pythons installed from python.org (or otherwise installed into /Library/Frameworks). Please check which python you are using. Using whatever command name you enter to start the failing python, try the following (I'll assume you use "python2.7"): type python2.7 The value for sys.executable should be: In any case, you could manually rename _readline.so as shown in one of the earlier messages (substituting "2.7" for "3.3"). Or you could install 2.7.6rc1. |
My mistake. I'm using -- On Wed, Oct 30, 2013 at 3:32 PM, Ned Deily <report@bugs.python.org> wrote:
|
I have installed 2.7.6 RC1 on OS X 10.9, and this bug still exists. See http://stackoverflow.com/questions/19722580/segfault-11-with-pandas-with-python-v2-7-6-rc1-on-mac-os-x-10-9 |
Russell, that's not related to readline. Please file a new bug report. |
So what's the resolution here? All I see is a script that disables the readline module depending on whether the interactive session crashes... Has a fix been pushed into the 3.4 release such that linking the readline module against editline results in a working interactive interpreter? |
Yes, this is fixed, as the issue resolution says. If you are curious about the fix, follow the links to the commits starting in msg197116. |
Thanks, I had missed that message. On 6/2/15 4:39 PM, R. David Murray wrote:
|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: