[skia] signal SIGILL, Illegal instruction from C:\msys64\mingw64\bin\libskia.dll

[ajlani7105]

Description / Steps to reproduce the issue

Code :

    auto interface = GrGLMakeNativeInterface(); // SK_API sk_sp<const GrGLInterface> GrGLMakeNativeInterface()
    GrDirectContext * sContext = GrDirectContexts::MakeGL(interface).release(); // program crash here  ?!

GDB message :

Thread 1 received signal SIGILL, Illegal instruction.
0x00007ffa6e44903a in GrContextThreadSafeProxyPriv::Make(GrBackendApi, GrContextOptions const&) () from C:\msys64\mingw64\bin\libskia.dll
The target architecture is set to "auto" (currently "i386:x86-64").

Disassembly :

GrContextThreadSafeProxyPriv::Make(GrBackendApi, GrContextOptions const&):
	push   %rsi                     
	push   %rbx                     
	sub    $0x28,%rsp               
	mov    %r8,%rbx                 
	mov    %rcx,%rsi                
	mov    $0xf0,%ecx               
	mov    %edx,0x48(%rsp)          
	call   0x7ffa6ccc1778 <operator new(unsigned long long)>
	vmovdqu64 (%rbx),%zmm0         // here 

Expected behavior

rendering GrDirectContext from ( GrDirectContexts::MakeGL API ) normally without crashing .

Actual behavior

crash

Verification

• I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MSYS_NT-10.0-26100

MINGW environments affected

• MINGW64
• MINGW32
• UCRT64
• CLANG64
• CLANGARM64

Are you willing to submit a PR?

No response

[ognevny]

was it regressed after recent PRs?

cc @raedrizqie

[ajlani7105]

was it regressed after recent PRs?

cc @raedrizqie

I don't think so, because right now I'm using the last update of Skia version 130.r73211.b988efa0-3
and recent PRs have the same issue too !

before that skia version were having MakeGL API in
which looks like
GrDirectContext * sContext = GrDirectContext::MakeGL(interface).release();

and now it looks like that
GrDirectContext * sContext = GrDirectContexts::MakeGL(interface).release();

skia devs were moving MakeGL function API to GrDirectContexts namespace instead of GrDirectContext object
the version before 130.r73211.b988efa0-3 were normall and there no crash

is this issue related to skia devs and not compiling issue for skia under mingw and msys ?

[raedrizqie]

skia is known for breaking their abi every now and then.. i think you better ask upstream for a better advice.

maybe you can use this as an example?
https://gist.github.com/ad8e/dd150b775ae6aa4d5cf1a092e4713add

[ajlani7105]

skia is known for breaking their abi every now and then.. i think you better ask upstream for a better advice.

horrible devs -_- , these changed no one asked for them !

maybe you can use this as an example? https://gist.github.com/ad8e/dd150b775ae6aa4d5cf1a092e4713add

this is what i have been using , as i said before it was working normally until the last update of skia and msys package

[lb90]

I think AVX512 support was added in google/skia@9cb4de5

Skia uses cpuid at runtime to detect if AVX512 is supported (and not IsProcessorFeaturePresent):

• https://github.com/google/skia/blob/main/modules/skcms/skcms.cc#L2468
• https://github.com/google/skia/blob/main/src/core/SkCpu.cpp#L62

I wonder what happens if one disables AVX support via BIOS? EDIT: should be ok as it checks xgetbv: https://stackoverflow.com/questions/72522885/are-the-xgetbv-and-cpuid-checks-sufficient-to-guarantee-avx2-support

[ajlani7105]

I think AVX512 support was added in google/skia@9cb4de5

Skia uses cpuid at runtime to detect if AVX512 is supported (and not IsProcessorFeaturePresent):

* https://github.com/google/skia/blob/main/modules/skcms/skcms.cc#L2468

* https://github.com/google/skia/blob/main/src/core/SkCpu.cpp#L62

I wonder what happens if one disables AVX support via BIOS? EDIT: should be ok as it checks xgetbv: https://stackoverflow.com/questions/72522885/are-the-xgetbv-and-cpuid-checks-sufficient-to-guarantee-avx2-support

I am not expert in cpu
but I was actually looking at -march=cpu-type flag in gcc, and I try to compile with different types of -march
it has to be something related to AVX512

[lb90]

IMO this could be https://randomascii.wordpress.com/2016/12/05/vc-archavx-option-unsafe-at-any-speed/

[raedrizqie]

@ajlani7105 how did you compile this code without error?

GrDirectContext * sContext = GrDirectContexts::MakeGL(interface).release();

I had to add #include "include/gpu/ganesh/gl/GrGLDirectContext.h" in order to make it compile:

g++ -g -std=c++17 -I/ucrt64/include/skia glfw_ship.cpp -lskia -lglfw3 -lopengl32 -lglu32

..but sadly I cannot run the exe: WGL: The driver does not appear to support OpenGL

[lb90]

but sadly I cannot run the exe: WGL: The driver does not appear to support OpenGL

Hi @raedrizqie! If you can't run the example, it might be useful to inspect the generated assembly. I am using Binary Ninja. Search the GrContextThreadSafeProxyPriv::Make symbol: GCC builds have the vmovdqu64 Instruction, CLang builds have vmovups.

[ajlani7105]

@ajlani7105 how did you compile this code without error?

GrDirectContext * sContext = GrDirectContexts::MakeGL(interface).release();

I had to add #include "include/gpu/ganesh/gl/GrGLDirectContext.h" in order to make it compile:

g++ -g -std=c++17 -I/ucrt64/include/skia glfw_ship.cpp -lskia -lglfw3 -lopengl32 -lglu32

..but sadly I cannot run the exe: WGL: The driver does not appear to support OpenGL

yes you can't compile

GrDirectContext * sContext = GrDirectContexts::MakeGL(interface).release();

without including <include/gpu/ganesh/gl/GrGLDirectContext.h>

[lb90]

I have built skia locally with MINGW_ARCH=ucrt64

Since GrContextThreadSafeProxyPriv::Make is defined in src/gpu/ganesh/GrContextThreadSafeProxy.cpp, I have checked the compiled .o file in out/Release-UCRT64/obj/src/gpu/ganesh. Turns out it contains vmovdqu64:

00000e70  struct COFF_Relocation*** 
00000e70      _ZN28GrContextThreadSafeProxyPriv4MakeE12GrBackendApiRK16GrContextOptions(
00000e70      struct COFF_Relocation*** arg1, int32_t arg2, uint64_t (* arg3)[0x8], int64_t arg4 @ k0)

00000e70  56                 push    rsi {__saved_rsi}
00000e71  53                 push    rbx {__saved_rbx}
00000e72  4883ec28           sub     rsp, 0x28
00000e76  4c89c3             mov     rbx, r8
00000e79  4889ce             mov     rsi, rcx
00000e7c  b9f0000000         mov     ecx, 0xf0
00000e81  89542448           mov     dword [rsp+0x48 {arg_10}], edx
00000e85  e856580000         call    _Znwy
00000e8a  62f1fe486f03       vmovdqu64 zmm0, k0, zmmword [rbx]
...

This the command-line used to build GrContextThreadSafeProxy.cpp:

g++ -MD -MF obj/src/gpu/ganesh/gpu.GrContextThreadSafeProxy.o.d -D_CRT_SECURE_NO_WARNINGS -DWIN32_LEAN_AND_MEAN -DNOMINMAX -DNDEBUG -DSK_CODEC_DECODES_BMP -DSK_CODEC_DECODES_WBMP -DSKIA_DLL -DSK_ENABLE_PRECOMPILE -DSK_GANESH -DSK_DISABLE_TRACING -DSK_GAMMA_APPLY_TO_A8 -DSK_ENABLE_AVX512_OPTS -DSKIA_IMPLEMENTATION=1 -DSK_GL -I../.. -mavx2 -mavx512f -mf16c -mfma -fpermissive -fstrict-aliasing -fvisibility=default -Wno-attributes -Wno-stringop-overflow -O3 -fdata-sections -ffunction-sections -std=c++17 -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -c ../../src/gpu/ganesh/GrContextThreadSafeProxy.cpp -o obj/src/gpu/ganesh/gpu.GrContextThreadSafeProxy.o

Which contains -mavx512f.

[raedrizqie]

@lb90 yes.. I had to add -mavx512f -mf16c -mfma to cflags in order to silenced some warnings. maybe its a bad idea?

[lb90]

Ah, thanks! Actually I couldn't find where that flag came from 😃

Ok, so it's https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-skia/0002-add-mingw-toolchain-skia.patch#L200

With that GCC can generate code that's not compatible with all CPUs. Let's see if we can address the warnings differently...

[ajlani7105]

I was looking in 0002-add-mingw-toolchain-skia.patch for -march=

i found :
https://github.com/raedrizqie/MINGW-packages/blob/4bd1abbb6c0c777ef6b49f8c7af2ada74ff56aa2/mingw-w64-skia/0002-add-mingw-toolchain-skia.patch#L411

and

https://github.com/raedrizqie/MINGW-packages/blob/4bd1abbb6c0c777ef6b49f8c7af2ada74ff56aa2/mingw-w64-skia/0002-add-mingw-toolchain-skia.patch#L429

so in 3.20.54 x86 Options page

why not compile with this option ? -march=native

‘native’

This selects the CPU to generate code for at compilation time by determining the processor type of the compiling machine.
Using -march=native enables all instruction subsets supported by the local machine (hence the result might not run on different machines).
 Using -mtune=native produces code optimized for the local machine under the constraints of the selected instruction set.

update :
I try to change to -march to native and adding -mavx and -mprefer-vector-width=512 with no luck , it's the same problem happen .