Segmentation fault: 11 in OS X
Question:
I am getting an issue in Python 3.3.2 on OSX 10.9 where if I open Python in a terminal window, it exits with “Segmentation error: 11” after the second line I enter, regardless of what the two commands are. For example, if I enter:
>>> for x in range(1000): print(x)
that works fine, but if I enter:
>>> for x in range(1000):
... print(x)
then I get the error when I press enter on the second line. I can also run a script with more than 2 lines without any problems.
I updated to OSX 10.9 this afternoon, so I suspect that may be it.
However, I just recently installed IPython (along with several other packages) and have been using that the past couple of days, so it could be something else I installed recently. I had a couple unsuccessful attempts at installing PyQt where I ran configure.py but then the “make” command failed, which I was also suspicious of.
I tried reinstalling Python, but it didn’t resolve the issue. Both IPython and IDLE work with no problems. I’m just concerned about what could be the underlying issue.
Answers:
This is a bug in the readline compatibility in python, related to changes introduced in OSX10.9. This weekend, release candidates for Python2.7.6 and Python3.3.3 were released which fix this bug. The download links are below.
http://python.org/download/releases/2.7.6/
http://python.org/download/releases/3.3.3/
Here’s the issue, quoting from Ned Deily, writing on the python-dev email list.
On Tuesday, Apple released OS X 10.9 (a.k.a. Mavericks). There has already
been a lot of interest in it, in part because Apple has made it available for
free and has made it easy for users with 10.8, 10.7, and (most) 10.6 systems
to upgrade directly to 10.9. Unfortunately, there are issues with our current
maintenance releases (3.3.2 and 2.7.5) on OS X 10.9 that call for new
maintenance releases as soon as possible.
One is critical in that it causes the interpreter to crash when running in
interactive mode (http://bugs.python.org/issue18458). The problem was due to
a long-standing compatibility issue in libedit’s readline compatibility layer
that upstream has finally fixed and Apple has now shipped in 10.9. Because
the python.org installers dynamically link to libedit, the original workaround
in readline.c for the original design flaw in history indexing now causes a
segfault on 10.9 when the user types in the second command interactively. Not
good. Ronald devised a fix that allows readline.so at runtime to detect and
work with either version of libedit so that we continue to have binary
compatibility across multiple OS X releases. That fix is already out in the
3.4.0 alphas and backported to the 3.3 and 2.7 branches, awaiting release
there. Just in the last 12 hours, there have been at least four duplicates of
the issue reported by users. I’ve updated the original issue to explicitly
mention 10.9, now that it is no longer under NDA, and to provide a
downloadable script for inexperienced users to workaround the problem by
“removing” readline.so. Presumably, as word gets out, there will be fewer
duplicate issues opened but the impact will remain.
I had this problem after upgrading to OS X 10.9 and used the patch provided on the Python website: http://bugs.python.org/issue18458#msg201087
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
openssl sha1 patch_readline_issue_18458.sh
# the digest should be 7cb0ff57820a027dd4ca242eb2418930f8f46b4c
then
sh ./patch_readline_issue_18458.sh
Enter your password, if prompted
I was encountering similar ‘segmentation fault 11’ errors but for me it was using mercurial(hg)
This was trying to use Python 2.7.8 installed via the .mpkg installer and pip install mercurial
On OS X 10.9.5
I thought updating to 2.7.8 would have resolved this but it seemed that mercurial was still looking for the System/Library/Frameworks/Python.framework/Versions/2.7
Even after trying to follow this slightly unwise advice Things still weren’t working. I would run
hg init
hg add *
hg commit -m ...
hg status
would get ‘segmentation fault 11’
The first couple of lines of the stack trace point to this:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 ??? 000000000000000000 0 + 0
1 osutil.so 0x00000001095ef768 listdir + 313
2 org.python.python 0x0000000109261b35 PyEval_EvalFrameEx + 14712
3 org.python.python 0x000000010925e093 PyEval_EvalCodeEx + 1641
In the end my solution seems to have come from (re)installing python with homebrew using that to get the 2.7.8 release (as of Dec 2014)
I then reinstalled mercurial with brew install mercurial which seems to have resolved whatever dependencies where causing this. I wish I understood better what was happening with the Seg fault but couldn’t get to the bottom of it.
The best guess I still have is that mercurial was still referencing the system python despite 2.7.8 being installed properly and usr/local/bin being first in the path
/usr/local/bin:usr/local/git/bin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/Library/Frameworks/Python.framework/Versions/3.4/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:~/Develop:/usr/local/git/bin: No such file or directory
So, what I’m suggesting is updating the python install with brew and then reinstalling whatever other packages you depend on.
I had this problem. Changing the chunksize in my csv parser to 100 eliminated the error.
I am getting an issue in Python 3.3.2 on OSX 10.9 where if I open Python in a terminal window, it exits with “Segmentation error: 11” after the second line I enter, regardless of what the two commands are. For example, if I enter:
>>> for x in range(1000): print(x)
that works fine, but if I enter:
>>> for x in range(1000):
... print(x)
then I get the error when I press enter on the second line. I can also run a script with more than 2 lines without any problems.
I updated to OSX 10.9 this afternoon, so I suspect that may be it.
However, I just recently installed IPython (along with several other packages) and have been using that the past couple of days, so it could be something else I installed recently. I had a couple unsuccessful attempts at installing PyQt where I ran configure.py but then the “make” command failed, which I was also suspicious of.
I tried reinstalling Python, but it didn’t resolve the issue. Both IPython and IDLE work with no problems. I’m just concerned about what could be the underlying issue.
This is a bug in the readline compatibility in python, related to changes introduced in OSX10.9. This weekend, release candidates for Python2.7.6 and Python3.3.3 were released which fix this bug. The download links are below.
http://python.org/download/releases/2.7.6/
http://python.org/download/releases/3.3.3/
Here’s the issue, quoting from Ned Deily, writing on the python-dev email list.
On Tuesday, Apple released OS X 10.9 (a.k.a. Mavericks). There has already
been a lot of interest in it, in part because Apple has made it available for
free and has made it easy for users with 10.8, 10.7, and (most) 10.6 systems
to upgrade directly to 10.9. Unfortunately, there are issues with our current
maintenance releases (3.3.2 and 2.7.5) on OS X 10.9 that call for new
maintenance releases as soon as possible.One is critical in that it causes the interpreter to crash when running in
interactive mode (http://bugs.python.org/issue18458). The problem was due to
a long-standing compatibility issue in libedit’s readline compatibility layer
that upstream has finally fixed and Apple has now shipped in 10.9. Because
the python.org installers dynamically link to libedit, the original workaround
in readline.c for the original design flaw in history indexing now causes a
segfault on 10.9 when the user types in the second command interactively. Not
good. Ronald devised a fix that allows readline.so at runtime to detect and
work with either version of libedit so that we continue to have binary
compatibility across multiple OS X releases. That fix is already out in the
3.4.0 alphas and backported to the 3.3 and 2.7 branches, awaiting release
there. Just in the last 12 hours, there have been at least four duplicates of
the issue reported by users. I’ve updated the original issue to explicitly
mention 10.9, now that it is no longer under NDA, and to provide a
downloadable script for inexperienced users to workaround the problem by
“removing” readline.so. Presumably, as word gets out, there will be fewer
duplicate issues opened but the impact will remain.
I had this problem after upgrading to OS X 10.9 and used the patch provided on the Python website: http://bugs.python.org/issue18458#msg201087
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
openssl sha1 patch_readline_issue_18458.sh
# the digest should be 7cb0ff57820a027dd4ca242eb2418930f8f46b4c
then
sh ./patch_readline_issue_18458.sh
Enter your password, if prompted
I was encountering similar ‘segmentation fault 11’ errors but for me it was using mercurial(hg)
This was trying to use Python 2.7.8 installed via the .mpkg installer and pip install mercurial
On OS X 10.9.5
I thought updating to 2.7.8 would have resolved this but it seemed that mercurial was still looking for the System/Library/Frameworks/Python.framework/Versions/2.7
Even after trying to follow this slightly unwise advice Things still weren’t working. I would run
hg init
hg add *
hg commit -m ...
hg status
would get ‘segmentation fault 11’
The first couple of lines of the stack trace point to this:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 ??? 000000000000000000 0 + 0
1 osutil.so 0x00000001095ef768 listdir + 313
2 org.python.python 0x0000000109261b35 PyEval_EvalFrameEx + 14712
3 org.python.python 0x000000010925e093 PyEval_EvalCodeEx + 1641
In the end my solution seems to have come from (re)installing python with homebrew using that to get the 2.7.8 release (as of Dec 2014)
I then reinstalled mercurial with brew install mercurial which seems to have resolved whatever dependencies where causing this. I wish I understood better what was happening with the Seg fault but couldn’t get to the bottom of it.
The best guess I still have is that mercurial was still referencing the system python despite 2.7.8 being installed properly and usr/local/bin being first in the path
/usr/local/bin:usr/local/git/bin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/Library/Frameworks/Python.framework/Versions/3.4/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:~/Develop:/usr/local/git/bin: No such file or directory
So, what I’m suggesting is updating the python install with brew and then reinstalling whatever other packages you depend on.
I had this problem. Changing the chunksize in my csv parser to 100 eliminated the error.