Examples segfault when run through virtual terminal

[burgerindividual]

Running any of the examples through a virtual terminal causes a crash. I'm on arch linux using an intel iGPU (i7-1260P). This happens in both the precompiled binaries, and binaries compiled on the latest commit (e16c711) with the release type set to debug and debug mode enabled. I was able to get a stack trace from a core dump, which I have attached. The compositor seems to mostly work when run through cage with the wayland EGL backend.

Log:

ryan@gram-arch ~> LOUVRE_DEBUG=4 SRM_DEBUG=4 ~/Documents/clones/Louvre/src/build/examples/louvre-views/louvre-views
Louvre debug: [LLauncher::startDaemon] LLauncher daemon started successfully with PID: 4691.
Louvre debug: [LCompositorPrivate::loadGraphicBackend] Graphic backend loaded successfully (/usr/local/lib/Louvre/backends/graphic/drm.so).
Louvre debug: [LSeatPrivate::initLibseat] Using libseat.
SRM debug: [core] SRM version 0.7.0-1.
SRM debug: [core] Custom scanout enabled: YES.
SRM debug: [core] Deallocator thread started.
SRM debug: [/dev/dri/card1] Is boot VGA: YES.
SRM debug: [/dev/dri/card1] Is master: YES.
SRM debug: [/dev/dri/card1] DRM Driver: i915.
Louvre debug: [LLauncher] Daemon exited with status 0.
fish: Job 1, 'LOUVRE_DEBUG=4 SRM_DEBUG=4 ~/Do...' terminated by signal SIGSEGV (Address boundary error)

Trace:

(lldb) bt
* thread #1, name = 'louvre-views', stop reason = signal SIGSEGV: invalid permissions for mapped object
  * frame #0: 0x00007dbcbeaa6a39 libc.so.6`pthread_mutex_lock + 89
    frame #1: 0x00007dbcbc383e88 libwayland-client.so.0`wl_proxy_create_wrapper + 56
    frame #2: 0x00007dbcbc42b10e libEGL_mesa.so.0`___lldb_unnamed_symbol743 + 702
    frame #3: 0x00007dbcbc4204c9 libEGL_mesa.so.0`___lldb_unnamed_symbol576 + 265
    frame #4: 0x00007dbcbc40e8ac libEGL_mesa.so.0`___lldb_unnamed_symbol355 + 428
    frame #5: 0x00007dbcbf43655c libSRM.so.0`srmDeviceInitializeEGL(device=0x0000596cd999d420) at SRMDevicePrivate.c:309:10
    frame #6: 0x00007dbcbf4362fc libSRM.so.0`srmDeviceCreate(core=0x0000596cd9968c40, name=<unavailable>, isBootVGA='\x01') at SRMDevicePrivate.c:126:10
    frame #7: 0x00007dbcbf43492b libSRM.so.0`srmCoreEnumerateDevices(core=0x0000596cd9968c40) at SRMCorePrivate.c:107:29
    frame #8: 0x00007dbcbf42fead libSRM.so.0`srmCoreCreate(interface=0x00007dbcbf4573f8, userData=<unavailable>) at SRMCore.c:78:10
    frame #9: 0x00007dbcbf45199f drm.so`Louvre::LGraphicBackend::backendInitialize() at LGraphicBackendDRM.cpp:326:18
    frame #10: 0x00007dbcbf4fc6ea libLouvre.so.2`Louvre::LCompositor::LCompositorPrivate::initGraphicBackend(this=0x0000596cd9943a50) at LCompositorPrivate.cpp:288:18
    frame #11: 0x00007dbcbf4b12f4 libLouvre.so.2`Louvre::LCompositor::start(this=0x00007ffc7df3a310) at LCompositor.cpp:215:17
    frame #12: 0x0000596ccda12c1b louvre-views`main((null)=<unavailable>, (null)=<unavailable>) at main.cpp:18:21
    frame #13: 0x00007dbcbea34e08 libc.so.6`___lldb_unnamed_symbol3261 + 120
    frame #14: 0x00007dbcbea34ecc libc.so.6`__libc_start_main + 140
    frame #15: 0x0000596ccd9f2675 louvre-views`_start + 37

[ehopperdietzel]

Hi, thanks for reporting this. It could be an SRM bug, but it's odd that it crashes when calling eglInitialize() here SRMDevicePrivate.c:309:10.

This line also suspicious:

frame #1: 0x00007dbcbc383e88 libwayland-client.so.0 wl_proxy_create_wrapper + 56

Are you sure you're launching them from a free TTY and not within another Wayland compositor? To launch them, you need to:

1. Switch to a free TTY, e.g., $ sudo chvt 5.
2. Unset the WAYLAND_DISPLAY environment variable, otherwise, the Wayland backend will be loaded: $ unset WAYLAND_DISPLAY.
3. Launch an example, e.g., $ louvre-views.

[ehopperdietzel]

I've just tried it on Manjaro, and all the examples work both inside a nested Wayland compositor and from a TTY. I tested it on a machine with a single Intel GPU.

I first installed libsrm and then louvre, and voilà, it works.

Not sure why it doesn't work for you :(

[burgerindividual]

I didn't first install libsrm, so maybe that's the issue. I'll try compiling the latest version and report back.

[burgerindividual]

No dice. It still crashes in the same way. This may be more of an SRM issue, though, as all of the SRM binaries (such as srm-display-info) fail in the same way during initialization.

[ehopperdietzel]

I believe I've found the cause of the bug. It seems that your implementation of eglGetDisplay() is returning a Wayland EGLDisplay instead of GBM, even when a GBM handle is passed. I replaced the call with eglGetPlatformDisplay(), which allows explicitly specifying a GBM display handle. I've added this change to the egl_fix branch of SRM. Could you check if this fixes it? It's still working fine for me.

[burgerindividual]

That worked! It feels really weird that this is actually EGL spec, but apparently your fix reflects what the spec recommends here. Very strange.

[ehopperdietzel]

Thank you so much for reporting this and taking the time to test it! Changes already in SRM v0.7.1-1.

[ehopperdietzel]

Also, if you're building it manually, make sure to complete the meson install step, as assets and backends need to be properly installed and located on your system. You might be running a compiled example from the build directory, which could be linking to lib/backends installed by your package manager.

[burgerindividual]

I did realize that I hadn't taken the right steps to have a clean install. I uninstalled the version from the AUR as well as my local build, and then ran meson install with the /usr prefix instead of /usr/local as that was giving me issues (even after running ldconfig). Unfortunately it still crashes with the same stack trace as before. Potentially my library versions conflict? I can check that tomorrow