Here's the backtrace:

"""
#0  0x0000003bfb20c9b1 in sem_wait () from /lib64/libpthread.so.0
#1  0x000000000051a7c3 in PyThread_acquire_lock (lock=0x17db0750, waitflag=1)
    at Python/thread_pthread.h:321
#2  0x000000000051a9b4 in find_key (key=1, value=0x0) at Python/thread.c:268
#3  0x000000000051abdc in PyThread_get_key_value (key=1) at Python/thread.c:360
#4  0x00000000005025b1 in PyGILState_GetThisThreadState () at Python/pystate.c:598
#5  0x00000000005024f5 in _PyGILState_Reinit () at Python/pystate.c:547
#6  0x0000000000521fc7 in PyOS_AfterFork () at ./Modules/signalmodule.c:979
#7  0x000000000052461d in posix_fork (self=0x0, noargs=0x0) at ./Modules/posixmodule.c:3695
"""

It's stuck in _PyGILState_Reinit(), when calling PyGILState_GetThisThreadState().
That's because in 2.7, TLS is emulated (see Python/thread.c), and it uses a global mutex.
If this mutex is locked at the time of fork(), then the next call to TLS primitives (even PyGILState_GetThisThreadState()) will deadlock.

Now, this particular bug is fixed in 2.7 since #13156, which backed-out  _PyGILState_Reinit() because it was only relevant for native TLS implementations.

The code is still present in 3.2 and and default, but this problem doesn't affect native TLS implementations.

Just to be extra safe, we PyThread_ReInitTLS() - which resets this global mutex on emulated implementations, and is just a no-op on pthread and windows - should be moved earlier in PyOS_AfterFork(), to avoid this type of deadlock (I mean, PyGILState_GetThisThreadState() deadlock after fork() is bad).
Patch attached.