在Python 2.7中使用"from __future__ import unicode_literals"导致段错误

Question

大家好~
我在一个网页应用中使用rest_framework时遇到了段错误（segfault），具体情况如下：

from rest_framework import viewsets    

最后，我发现问题出现在这里：

>>> from __future__ import unicode_literals
Segmentation fault

但我不知道接下来该怎么做，所以我在这里寻求一些帮助。感谢任何建议。

顺便说一下：
1. 我对比了一个正常的__future__.py文件和这个有问题的__future__.py文件，但没有发现任何问题。
2. 我尝试了不同版本的django-rest-framework，所以我能找到上面提到的问题。

可能有用的信息：
平台：Linux 3.2.12-gentoo #1 SMP
Python版本：Python 2.7.3（默认，2012年10月8日，16:37:44）[GCC 4.4.5]在linux2上运行

######更新信息。非常感谢你们；-)########
核心的详细信息：

# gdb python core
GNU gdb (Gentoo 7.3.1 p2) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /bin/python...done.
[New LWP 6349]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Core was generated by `python'.
Program terminated with signal 11, Segmentation fault.
#0  binary_iop1 (op_slot=<optimized out>, iop_slot=<optimized out>, w=<optimized
1280    Objects/abstract.c: No such file or directory.
    in Objects/abstract.c
(gdb) bt
#0  binary_iop1 (op_slot=<optimized out>, iop_slot=<optimized out>, w=<optimized out>, v=<optimized out>) at Objects/abstract.c:1280
#1  binary_iop (op_name=<optimized out>, op_slot=<optimized out>, iop_slot=<optimized out>, w=<optimized out>, v=<optimized out>) at Objects/abstract.c:1298
#2  PyNumber_InPlaceTrueDivide (v=0x39, w=0xb76e03d0) at Objects/abstract.c:1332
#3  0x080e0f54 in PyEval_EvalFrameEx (f=0x88a1f7c, throwflag=0) at Python/ceval.c:1514
#4  0x080e6a44 in PyEval_EvalCodeEx (co=0xb751d9b0, globals=0xb757035c, locals=0xb757035c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:3263
#5  0x080e6b77 in PyEval_EvalCode (co=0xb751d9b0, globals=0xb757035c, locals=0xb757035c) at Python/ceval.c:669
#6  0x08103f27 in run_mod (arena=<optimized out>, flags=<optimized out>, locals=<optimized out>, globals=<optimized out>, filename=<optimized out>, mod=<optimized out>)
at Python/pythonrun.c:1353
#7  PyRun_InteractiveOneFlags (fp=0xb76df440, filename=0x815b7a4 "<stdin>", flags=0xbfbb23ec) at Python/pythonrun.c:852
#8  0x08104198 in PyRun_InteractiveLoopFlags (fp=0xb76df440, filename=0x815b7a4 "<stdin>", flags=0xbfbb23ec) at Python/pythonrun.c:772
#9  0x081049e5 in PyRun_AnyFileExFlags (fp=0xb76df440, filename=0x815b7a4 "<stdin>", closeit=0, flags=0xbfbb23ec) at Python/pythonrun.c:741
#10 0x0805bacd in Py_Main (argc=1, argv=0xbfbb24d4) at Modules/main.c:674
#11 0x0805abab in main (argc=1, argv=0xbfbb24d4) at ./Modules/python.c:23
(gdb)

Answer 1

要解决你现在遇到的问题，你可以在每个使用的字符串前加一个 u，比如把 'foo' 改成 u'foo' 等等。当然，这样会需要改很多代码，但是：

段错误（Segmentation Fault）总是和Python的实现有关（无论是核心语言解释器还是正在使用的模块）。在Python语言中是无法产生段错误的，因为这种内存管理对Python开发者来说是隐藏的。

这意味着这种类型的错误需要在Python语言或模块的实现中修复。你应该把你的信息作为错误报告提供给有问题的代码的开发者。可以通过生成核心文件并进行分析来找到有问题的代码。你能这么容易地重现这个问题真是个幸运的巧合，所以你可以配置你的命令行来生成核心文件：

$ ulimit -c unlimited

然后产生段错误：

$ python
>>> from __future__ import unicode_literals
Segmentation fault (core dumped)

现在你应该有一个核心文件，可以在Gnu调试器中加载它：

$ gdb /usr/bin/python core   # maybe adjust path-to-python for your system
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
...
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `python'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f21c08705d5 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb)

或者类似的操作。然后输入：

(gdb) bt

这将打印出导致段错误的大量回溯信息（第0帧是引发问题的地方，第1帧调用了第0帧，依此类推，所以这个回溯是从内到外的）。也许你可以通过函数的名称等信息找出涉及的模块。然后你应该把这个回溯信息提供给相关模块的开发者。他们是解决这个问题的人。