Comment # 31 on bug 976293 from Giuseppe Gorgoglione

Luckily the crash is very deterministic. It happens in thread 0 and a partial
stacktrace is this.

1    ED_region_do_draw        area.c        479    0x10ce110    
2    wm_method_draw_overlap_all    wm_draw.c    289    0x9c5164    
3    wm_draw_update            wm_draw.c    953    0x9c8b84    
4    WM_main                wm.c        495    0x9bdbc8    
5    main                creator.c    2102    0x96b855    

ED_region_do_draw() is called many times without problems but at a certain time
it crashes. I'm still investigating to find the exact crashing spot.

I can do source level debugging for blender itself but not for the crashing
spot.
Nevertheless it is also very deterministic and the disassembly looks like this:

0x7f3282a621aa                   83 c7 0c                    add    $0xc,%edi
0x7f3282a621ad                   18 d2                       sbb    %dl,%dl
0x7f3282a621af                   c4 41 31 ef c9              vpxor 
%xmm9,%xmm9,%xmm9
0x7f3282a621b4                   c4 41 29 ef d2              vpxor 
%xmm10,%xmm10,%xmm10
0x7f3282a621b9                   44 39 f7                    cmp    %r14d,%edi
0x7f3282a621bc                   77 6d                       ja    
0x7f3282a6222b
0x7f3282a621be                   c4 c1 79 92 c7              kmovb  %r15d,%k0
0x7f3282a621c3                   c5 f8 93 f8                 kmovw  %k0,%edi
0x7f3282a621c7                   81 e7 01 00 00 00           and    $0x1,%edi
0x7f3282a621cd                   c4 41 29 ef d2              vpxor 
%xmm10,%xmm10,%xmm10
0x7f3282a621d2                   40 84 ff                    test   %dil,%dil
0x7f3282a621d5                   75 54                       jne   
0x7f3282a6222b
0x7f3282a621d7                   81 e3 01 00 00 00           and    $0x1,%ebx
0x7f3282a621dd                   c5 f8 92 c3                 kmovw  %ebx,%k0
0x7f3282a621e1                   c5 f8 93 f8                 kmovw  %k0,%edi
0x7f3282a621e5                   81 e7 01 00 00 00           and    $0x1,%edi
0x7f3282a621eb                   c4 41 29 ef d2              vpxor 
%xmm10,%xmm10,%xmm10
0x7f3282a621f0                   40 84 ff                    test   %dil,%dil
0x7f3282a621f3                   75 36                       jne   
0x7f3282a6222b
0x7f3282a621f5                   81 e2 01 00 00 00           and    $0x1,%edx
0x7f3282a621fb                   c5 f8 92 c2                 kmovw  %edx,%k0
0x7f3282a621ff                   c5 f8 93 d0                 kmovw  %k0,%edx
0x7f3282a62203                   81 e2 01 00 00 00           and    $0x1,%edx
0x7f3282a62209                   c4 41 29 ef d2              vpxor 
%xmm10,%xmm10,%xmm10
0x7f3282a6220e                   84 d2                       test   %dl,%dl
0x7f3282a62210                   75 19                       jne   
0x7f3282a6222b
0x7f3282a62212                   48 98                       cltq
0x7f3282a62214                   62 d1 fe 08 7e 0c 01        vmovq 
(%r9,%rax,1),%xmm1
0x7f3282a6221b                   62 d3 75 08 21 4c 01 02 20  vinsertps
$0x20,0x8(%r9,%rax,1),%xmm1,%xmm1

The crash is always on line 7, "kmovb  %r15d,%k0", which is an AVX-512
instruction.