Running pulseeffects, it crashes occasionally.  I have yet to find a cause, it just happens. 
I decided to run it under gdb to catch the crash.  It worked  for a few days before crashing.

$ GDK_DPI_SCALE=0.6 gdb -args /usr/bin/python3 /usr/bin/pulseeffects 

gdb: Symbol `acs_map' has different size in shared object, consider re-linking
GNU gdb (GDB) 7.8-1pclos2014 (PCLinuxOS release 2014)
...
...
13:57:26.125 - PulseEffects - CRITICAL - PM - context operation  failed!
13:57:29.779 - PulseEffects - CRITICAL - PM - context operation  failed!
13:57:30.391 - PulseEffects - CRITICAL - PM - context operation  failed!
[New LWP 27696]

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 27696]
0x00007ffff73bcae6 in ?? () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff73bcae6 in  () at /lib64/libc.so.6
#1  0x00007ffff29f8e08 in  ()
    at /usr/lib64/python3.6/lib-dynload/_ctypes.cpython-36m-x86_64-linux-gnu.so
#2  0x00007ffff79baf1e in _PyObject_GenericGetAttrWithDict ()
    at /usr/lib64/libpython3.6m.so.1.0
#3  0x00007ffff7a2b6b0 in _PyEval_EvalFrameDefault ()
    at /usr/lib64/libpython3.6m.so.1.0
#4  0x00007ffff7a271df in  () at /usr/lib64/libpython3.6m.so.1.0
#5  0x00007ffff7a2fce0 in _PyFunction_FastCallDict ()
    at /usr/lib64/libpython3.6m.so.1.0
#6  0x00007ffff79719fe in _PyObject_FastCallDict ()
    at /usr/lib64/libpython3.6m.so.1.0
#7  0x00007ffff7971c0d in _PyObject_Call_Prepend ()
    at /usr/lib64/libpython3.6m.so.1.0
#8  0x00007ffff79717c8 in PyObject_Call () at /usr/lib64/libpython3.6m.so.1.0
#9  0x00007ffff29f433d in  ()
    at /usr/lib64/python3.6/lib-dynload/_ctypes.cpython-36m-x86_64-linux-gnu.so
#10 0x00007ffff3f73dcf in ffi_closure_unix64_inner () at /usr/lib64/libffi.so.6
#11 0x00007ffff3f74148 in ffi_closure_unix64 () at /usr/lib64/libffi.so.6
#12 0x00007fffde2abaf5 in  () at /usr/lib64/libpulse.so.0
#13 0x00007fffddf27ce1 in  () at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#14 0x00007fffddf28033 in pa_pdispatch_run ()
    at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#15 0x00007fffde2aaa9e in  () at /usr/lib64/libpulse.so.0
#16 0x00007fffddf2ab4f in  () at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#17 0x00007fffddf2d5db in  () at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#18 0x00007fffddf2d979 in  () at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#19 0x00007fffddf2e1df in  () at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#20 0x00007fffde2bea58 in pa_mainloop_dispatch () at /usr/lib64/libpulse.so.0
#21 0x00007fffde2bee1e in pa_mainloop_iterate () at /usr/lib64/libpulse.so.0
#22 0x00007fffde2beea0 in pa_mainloop_run () at /usr/lib64/libpulse.so.0
#23 0x00007fffde2cc786 in  () at /usr/lib64/libpulse.so.0
#24 0x00007fffddf3db48 in  () at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#25 0x00007ffff76ed62e in  () at /lib64/libpthread.so.0
#26 0x00007ffff7421def in clone () at /lib64/libc.so.6
(gdb) 


Seems to be a python bug not validating a data pointer.

A similar bug was fixed here  https://bugs.python.org/issue12149

reviewing the code https://github.com/python/cpython/blob/master/Objects/object.c

I think line 981 mentioned in the bug description is now line 1235

f = descr->ob_type->tp_descr_get;

Which now is protected inside an if (descr != NULL). So they fixed it here. 
Further just below that both 'f' and 'descr' are used like this


if (f != NULL && PyDescr_IsData(descr)) {
res = f(descr, obj, (PyObject *)obj->ob_type);

The problem now seem to be further below (line 1279)  where the code is

if (f != NULL) {
res = f(descr, obj, (PyObject *)Py_TYPE(obj));

The problem is that they forget to check that descr is valid.