SilkBackedSkiaRendering crashes on Linux

[jspa2]

Summary

The SilkBackedSkiaRendering experiment crashes on my Linux installation.

A blank, black window briefly pops up, and then closes.

Steps to reproduce

• Platform: Desktop Linux
• Framework Version: .NET 6.0.10
• API: OpenGL
• API Version: OpenGL 4.6

1. Run the SilkBackedSkiaRendering project in /src/Lab/Experiments/SilkBackedSkiaRendering.

Comments

Additional information: Silk.NET version 2.16.0 SkiaSharp version 2.88.3 Distro: Arch Linux Wayland

[Beyley]

Stack trace?

[jspa2]

Stack trace?

It simply exits with code 0 after GRGlInterface.Create.

[Beyley]

Stack trace?

It simply exits with code 0 after GRGlInterface.Create.

Run it under GDB and see if it can catch anything

[Perksey]

It's worth noting a more complete example of using Silk.NET with Skia is available in Trains.NET: https://github.com/davidwengier/Trains.NET/blob/main/src/SilkTrains/Program.cs

[jspa2]

Stack trace?

It simply exits with code 0 after GRGlInterface.Create.

Run it under GDB and see if it can catch anything

GDB shows:

[New Thread 0x7fff7d60f6c0 (LWP 7952)]
[New Thread 0x7fff7ce0e6c0 (LWP 7953)]
[New Thread 0x7fff77fff6c0 (LWP 7954)]
[New Thread 0x7fff777fe6c0 (LWP 7955)]
[New Thread 0x7fff76ffd6c0 (LWP 7956)]
[New Thread 0x7fff763ff6c0 (LWP 7957)]
[New Thread 0x7fff74a2c6c0 (LWP 7958)]
[New Thread 0x7fff34dff6c0 (LWP 7959)]
[New Thread 0x7fff2ffff6c0 (LWP 7960)]
[New Thread 0x7fff2f7fe6c0 (LWP 7961)]
[New Thread 0x7fff2effd6c0 (LWP 7962)]

Thread 1 "app" received signal SIGSEGV, Segmentation fault.
0x00007fff2deebf63 in ?? () from /home/user/app/bin/Debug/net6.0/runtimes/linux-x64/native/libSkiaSharp.so

[Beyley]

Stack trace?

It simply exits with code 0 after GRGlInterface.Create.

Run it under GDB and see if it can catch anything

GDB shows:

[New Thread 0x7fff7d60f6c0 (LWP 7952)]
[New Thread 0x7fff7ce0e6c0 (LWP 7953)]
[New Thread 0x7fff77fff6c0 (LWP 7954)]
[New Thread 0x7fff777fe6c0 (LWP 7955)]
[New Thread 0x7fff76ffd6c0 (LWP 7956)]
[New Thread 0x7fff763ff6c0 (LWP 7957)]
[New Thread 0x7fff74a2c6c0 (LWP 7958)]
[New Thread 0x7fff34dff6c0 (LWP 7959)]
[New Thread 0x7fff2ffff6c0 (LWP 7960)]
[New Thread 0x7fff2f7fe6c0 (LWP 7961)]
[New Thread 0x7fff2effd6c0 (LWP 7962)]

Thread 1 "app" received signal SIGSEGV, Segmentation fault.
0x00007fff2deebf63 in ?? () from /home/user/app/bin/Debug/net6.0/runtimes/linux-x64/native/libSkiaSharp.so

type bt to get a stack trace

[jspa2]

type bt to get a stack trace

@Beyley, this is the stack trace from GDB:

(gdb) bt
#0  0x00007fff2deebf63 in ?? () from /home/user/app/bin/Debug/net6.0/runtimes/linux-x64/native/libSkiaSharp.so
#1  0x00007fff2dee8de8 in ?? () from /home/user/app/bin/Debug/net6.0/runtimes/linux-x64/native/libSkiaSharp.so
#2  0x00007fff2deebba0 in ?? () from /home/user/app/bin/Debug/net6.0/runtimes/linux-x64/native/libSkiaSharp.so
#3  0x00007fff2dc77def in gr_glinterface_assemble_interface () from /home/user/app/bin/Debug/net6.0/runtimes/linux-x64/native/libSkiaSharp.so
#4  0x00007fff7e7d399a in ?? ()
#5  0x00007fffffffd010 in ?? ()
#6  0x0000000000000000 in ?? ()

[Perksey]

This looks like a Skia bug, but failing that this is a bug report against strictly experimental code (assume that everything in src/Lab is broken).

This code is probably a better reference for silk backed skia rendering: https://github.com/davidwengier/Trains.NET/blob/main/src/SilkTrains/Program.cs

Hope this helps.

[peteruhnak]

Just a note since I ran into this issue as well -- it seems to be enough to just let it create itself.

Can create a PR, but have no clue if this breaks on Windows/Mac.

- using var grGlInterface = GRGlInterface.Create((name => window.GLContext!.TryGetProcAddress(name, out var addr) ? addr : (IntPtr) 0));
+ using var grGlInterface = GRGlInterface.Create();

[Perksey]

You can create a PR if you’d like, but do note that we do not maintain any code in src/Lab so it’s probably all broken.

If you omit that parameter, where does Skia get the GL functions from?

[fabyr]

Can confirm this is still happening.

OpenGL 3.3.0 (NVIDIA 580.65.06)

.net8/.net6 Silk.NET 2.22.0 SkiaSharp 3.119.0 SkiaSharp.NativeAssets.Linux ships with libglfw.so.3 and libSkiaSharp.so.119.0.0

gdb gives me the same stack trace with segfault as already mentioned above

It does work by just calling Create with no arguments, but it seems? to fall back to software rendering in that case. But I can't confirm that for sure.

Either the issue is within SkiaSharp's GRGlInterface or in Silk.NET's TryGetProcAddress

[fabyr]

If I log what procedures are passed to the GRGlGetProcedureAddressDelegate,

window.Initialize();

GRGlInterface.Create(name => {
    bool ok = window.GLContext!.TryGetProcAddress(name, out nint addr);
    Console.WriteLine($"name: {name} - ok: {ok} - addr: 0x{addr:x8}");
    return ok ? addr : 0;
});

this is what I get:

name: glGetString - ok: True - addr: 0x7f2d8c7946c0
name: glGetString - ok: True - addr: 0x7f2d8c7946c0
name: glGetStringi - ok: True - addr: 0x7f2d8c7946e0
name: glGetIntegerv - ok: True - addr: 0x7f2d8c792ce0
name: eglQueryString - ok: True - addr: 0x7f2d8c7a5300
name: eglGetCurrentDisplay - ok: True - addr: 0x7f2d8c7a5320

Interestingly, it always seems to fail after eglGetCurrentDisplay. If I check for the name and purposefully return 0 for this one function name, the window starts up fine.

glInterface = GRGlInterface.Create(name => {
    if (name == "eglGetCurrentDisplay")
        return 0;

    return window.GLContext!.TryGetProcAddress(name, out nint addr) ? addr : 0;
});

Now either the address that is returned by TryGetProcAddress is faulty, or the implementation of eglGetCurrentDisplay breaks for some reason.

[Perksey]

Is your window even using EGL? This seems odd and I can understand it failing on that.

[fabyr]

I am following the very small example in Lab/ExperimentsSilkBackedSkiaRendering

It had been mentioned that code inside Lab is no longer maintained, but I have found a very similar usage in another project: Trains.NET

I am calling Silk.NET.Windowing.Glfw.GlfwWindowing.Use(); at the very start, so I'd assume my window would use higher level Glfw instead of EGL.