This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Setting PYTHONEXECUTABLE can cause segfaults on OS X
Type: crash Stage: resolved
Components: macOS Versions: Python 3.2, Python 3.3
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: ronaldoussoren Nosy List: ned.deily, ronaldoussoren
Priority: high Keywords:

Created on 2012-08-22 08:21 by ned.deily, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
issue15761.txt ronaldoussoren, 2012-08-22 08:59 review
Messages (4)
msg168856 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2012-08-22 08:21
Setting the environment variable PYTHONEXECUTABLE can cause the interpreter to crash with a segfault or to otherwise fail during initialization.  Another manifestation is the failure of test test_osx_env with:

AssertionError: -10 != 2 : expected PYTHONEXECUTABLE == sys.executable

(-10 means the interpreter subprocess under test segfaulted)

I have not yet been able to identify the root cause or the minimum set of conditions to produce a crash.  So far it seems that the interpreter must be 32-bit and running on 10.6 or later.  In all of the failures I've seen, PYTHONEXECUTABLE was set to an absolute path, not necessarily a valid path.  When running a debug build, I've seen two failure modes:

Assertion failed: (value), function PyDict_SetItem, file 
Objects/dictobject.c, line 1197.

#0  0x942a9332 in __kill ()
#1  0x942a8932 in kill$UNIX2003 ()
#2  0x98563c0c in abort ()
#3  0x9859820b in __assert_rtn ()
#4  0x00091b0f in PyDict_SetItem (op=0x48f438, key=0x487610, value=0x0) at Objects/dictobject.c:1197
#5  0x0009669d in PyDict_SetItemString (v=0x48f438, key=0x30ccfd "version", item=0x0) at Objects/dictobject.c:2695
#6  0x00245616 in make_impl_info (version_info=0x0) at ./Python/sysmodule.c:1525
#7  0x00244a00 in _PySys_Init () at ./Python/sysmodule.c:1690
#8  0x0022fdc1 in _Py_InitializeEx_Private (install_sigs=1, install_importlib=1) at Python/pythonrun.c:334
#9  0x00231577 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:401
#10 0x0023159a in Py_Initialize () at Python/pythonrun.c:407
#11 0x00269138 in Py_Main (argc=3, argv=0x446028) at Modules/main.c:646

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'

#0  0x942a9332 in __kill ()
#1  0x942a8932 in kill$UNIX2003 ()
#2  0x98563c0c in abort ()
#3  0x001a8d09 in Py_FatalError (
    msg=0x2506d4 "Py_Initialize: unable to load the file system codec")
    at Python/pythonrun.c:2358
#4  0x001a3320 in _Py_InitializeEx_Private (install_sigs=1, install_importlib=1)
    at Python/pythonrun.c:374
#5  0x001a3442 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:401
#6  0x001a3456 in Py_Initialize () at Python/pythonrun.c:407
#7  0x001cd0f2 in Py_Main (argc=1, argv=0x394028) at Modules/main.c:646
#8  0x000025e7 in main (argc=1, argv=0xbffff994) at python.c:66

Inspecting and gdb stepping through main.c, getpath.c, and pythonrun.c has not uncovered anything obvious yet.  Note, there have been changes in these areas for 3.3 in support of venv and bug fixes.

PYTHONEXECUTABLE is a somewhat vestigial environment variable supported only on OS X.  AFAIK, it was only intended for used with the deprecated tool but it is externally documented; it's also still used by initialization which is based on bundlebuilder.  So it might not be a release blocker to fix immediately but it is disquieting.  As there are other higher priority issues at the moment, I probably won't be able to get back to this until after rc1.
msg168860 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2012-08-22 08:59
There could be an off by one error in the decoding of PYTHONEXECUTABLE, mbstowcs will only add a NUL character when there is room for one and when the environment variable is all ASCII the buffer isn't large enough which means the argument to Py_SetProgramName is not NUL-terminated unless there happens to be a NUL byte just beyond the allocated buffer.

The attached patch ensures that there is room for a NUL character. I don't know if this actually fixes the crash as I've been unable to reproduce the issue (with various values of PYTHONEXECUBLE and with/without malloc checking environment variables (see malloc(3)).
msg168861 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2012-08-22 09:11
I can now reproduce the isue:

env PYTHONHOME=/Library/Frameworks/Python.framework/Versions/3.3  PYTHONEXECUTABLE=/bin/bash  MallocGuardEdges=1 MallocStackLogging=1 MallocScribble=1 MallocStackLoggingNoCompact=1 MallocCheckHeapEach=1 arch -i386 python3.3 -c 'import sys; print(sys.executable)'

This also fails with Python 3.2, but then it fails with a unicode error

UnicodeEncodeError: 'utf-8' codec can't encode character '\udffa' in position 17: surrogates not allowed

The error goes away when I used a patched version of python.exe, but that's one was not a framework build. 

Next step: rebuild and reinstall the 3.3 framework with my patch and check that the problem goes away.

All of this on an OSX 10.8 box, deployment target 10.8 and archs=intel.

Other notes:
* The 'Malloc....' variables aren't necessary to reproduce
* 'arch -i386' is necessary, no crash with 'arch -x86_64'
msg168878 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2012-08-22 12:43
committed a patch in revisions 526c6262d91f and ae51329f9893. Those won't end up as messages in this issue due to a typo in the check-in message.
Date User Action Args
2022-04-11 14:57:35adminsetgithub: 59965
2012-08-27 09:31:34ronaldoussorensetstatus: open -> closed
resolution: fixed
stage: resolved
2012-08-22 12:43:24ronaldoussorensetmessages: + msg168878
2012-08-22 09:11:08ronaldoussorensetversions: + Python 3.2
2012-08-22 09:11:01ronaldoussorensetmessages: + msg168861
2012-08-22 08:59:11ronaldoussorensetfiles: + issue15761.txt

messages: + msg168860
2012-08-22 08:21:46ned.deilycreate