Finally here is issue8112 which remove the CellRendererBinary and so its vfunc. So it left only CellRendererButton with a render vfunc but it does not seem to cause trouble.
So for me with all those patches, I can not reproduce the crash anymore.

With issue8111, I have repeated the action of attaching files more than 50 times without crash nor any GTK warning. But I think we should still reduce any usage of vfunc but at least issue8111 is back-portable.

Indeed review53391002 does not fix it, I could reproduce the crash.
So I tried the other suggestion to replace vfunc by signal in review66371002. The code is simpler but I could still reproduce the crash.

I tried to understand this error. I could reproduce it (especially on Windows) by creating attachment on the editable list view and selecting a file. This does not happen each time but it requires to repeat this operations many times.
I run with debug symbol on Gtk and GObject and I got this traceback:
#0 0x63c6b506 in g_type_check_instance_is_fundamentally_a (
type_instance=type_instance@entry=0x6,
fundamental_type=fundamental_type@entry=80)
at ../../glib-2.56.2/gobject/gtype.c:4023
#1 0x63c4a44c in g_object_ref (_object=0x6)
at ../../glib-2.56.2/gobject/gobject.c:3206
#2 0x710ce24b in gdk_event_copy () from C:\msys32\mingw32\bin\libgdk-3-0.dll
#3 0x63c6c0f6 in _g_type_boxed_copy (type=type@entry=59999912,
value=value@entry=0x5471c90) at ../../glib-2.56.2/gobject/gtype.c:4298
#4 0x63c44143 in g_boxed_copy (boxed_type=59999912, src_boxed=0x5471c90)
at ../../glib-2.56.2/gobject/gboxed.c:343
#5 0x6890c401 in gi-cpython-37m!PyInit__gi ()
from C:\msys32\mingw32\lib\python3.7\site-packages\gi\_gi-cpython-37m.dll
#6 0x000000a3 in ?? ()
#7 0x660c4819 in ?? () from C:\msys32\mingw32\bin\libgirepository-1.0-1.dll
#8 0x05471c90 in ?? ()
#9 0x00000007 in ?? ()
#10 0x00000007 in ?? ()
#11 0x00000000 in ?? ()
So the gi try to make a boxed copy of an object which seems to be a GdkEvent. The copy fails because the event is not valid (the window attribute if 0x6 (which is unbound)).
I put a print statement in gdk_event_copy to see the type of the event. Each time it fails, the event is of a type which is not part of the enum. So it looks like memory junk.
I tried to find a place where such event could be instantiated but I could not find it.

>
> Then it should be traced under gdb to get the backtrace.
>
Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x00007ffff632ac07 in g_type_check_instance_is_fundamentally_a () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
PS: @bernatnan could you avoid posting legal notice on the bugtracker, this
> is a public service and such notice has no place here.
Yes. Sorry, I have see it too late.