"from __future__ import unicode_literals" gives segfault in python 2.7
Question: all~  
The segfault occured while i try to use rest_framework in a webapp as this:

    
    
    from rest_framework import viewsets    
    

finally, i pointed the problem occured here:

    
    
    >>> from __future__ import unicode_literals
    Segmentation fault
    

but i have no idea for the next, so i posted here for some help. thx for any
advice.

FYI:  
1\. I have compared a normal __future__.py with this buggy __future__.py. But
i found nothing.  
2\. I have tried the different version of django-rest-framework, so i can get
the piont above.

Something may be useful:  
platform: Linux 3.2.12-gentoo #1 SMP  
python: Python 2.7.3 (default, Oct 8 2012, 16:37:44) [GCC 4.4.5] on linux2

######Update Info. Really thx for U;-)########  
The details of core:

    
    
    # 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: To solve your current issue you can place a `u` before each used string
literal, so out of `'foo'` make `u'foo'` etc. This of course can be a lot of
code to change, **BUT** :

Segmentation Faults are _always_ a problem within the implementation of Python
(either the core language interpreter or a module in use). There is no way
within the Python language to produce a Segmentation Fault because this kind
of memory management is hidden from the Python developer.

This means that this kind of bug needs to be fixed within the implementation
of the Python language or module. You should provide your information as a bug
report to the developers of the faulty code. The faulty code can be be found
by producing a core file and analyzing this. It is a lucky coincidence that
you can reproduce the problem so easily, so you can configure your shell to
produce core files:

    
    
    $ ulimit -c unlimited
    

Then produce the Segfault:

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

Now you should have a core file and can load this in the Gnu debugger:

    
    
    $ 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)
    

Or something like this. Then type:

    
    
    (gdb) bt
    

This will print a large backtrace of the situation which lead to the Segfault
(frame #0 will be the one who raised the problem, frame #1 called frame #0
etc., so this backtrace is innermost-first). Maybe you can figure out by the
names of the functions etc. which module is involved. Then you should provide
this backtrace to the developers of the involved module. They are the ones to
solve the issue at hand.

