Code:
# -------------------------------

__obj = object()

class Foo:
    def f1(self):
        nonlocal __obj

f = Foo()
f.f1()  # <-- segmentation fault
#
```-------------------------------

I get a crash when just compile the example.

I don't think the problem is about the underscores, since this work...

class Foo:
    def f1(self):
        __obj = object()
        def f2():
            nonlocal __obj
            __obj = []
        f2()
        return isinstance(__obj, list)
        
f = Foo()
print(f.f1())

The problem happens only when "nonlocal __something" in a class method. In your case f2() isn't class method.

More interesting behavior with underscores - https://gist.github.com/sirkonst/6eff694c4546700417ea

quoting the docs:

The statement [nonlocal] allows encapsulated code to rebind variables outside of the local scope BESIDES the global (module) scope.

Yes. Case:

# -------------------

class A:
    def f(self):
        nonlocal __x
# 

must raises SyntaxError like case:

# -------------------

class A:
    def f(self):
        nonlocal x

> SyntaxError: no binding for nonlocal 'x' found
# -------------------

but doesn't crash with SegFault as it is now.

New changeset 4fa8c0c69ee9 by Benjamin Peterson in branch '3.5':
make recording and reporting errors and nonlocal and global directives more robust (closes bpo-25973)
https://hg.python.org/cpython/rev/4fa8c0c69ee9

New changeset c64e68d703cf by Benjamin Peterson in branch 'default':
merge 3.5 (bpo-25973)
https://hg.python.org/cpython/rev/c64e68d703cf

So no fix for 3.4 for an obvious SIGSEGV?

    % python3  
    Python 3.4.3 (default, Mar 26 2015, 22:03:40) 
    [GCC 4.9.2] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> class A:
    ...     def f(self):
    ...         nonlocal __x
    ... 
    [4]    19173 segmentation fault (core dumped)  python3

Only security fixes are accepted for 3.4.

And as some additional background as to why segmentation faults provoked by Python code aren't currently considered a security bug: since CPython doesn't include a security sandbox, we're already relying entirely on the OS to provide process isolation.

That OS level security boundary isn't affected by whether the code is running "normally", or in a modified state following a deliberately triggered segmentation fault.