glxgears (+ applications creating a new gl context) fail to launch in Simula

[georgewsinger]

Example:

$ DISPLAY=:1 glxgears
Error: couldn't get an RGB, Double-buffered visual

Duplicated by @lwneal in Discord chat:

As for the OpenGL-inside-SimulaVR question, I still haven't figured out whether it's something trivial (like an envvar set the wrong way) or something deeply structural. Basically, a program like glxgears or any hello-world program that initialized an openGL context, fails when run within Simula After fixing a few things like LD_LIBRARY_PATH I can actually run something like DISPLAY=:1 glxgears from a terminal inside Simula, and it works- but it displays the OpenGL-rendered window on the monitor, not within the VR workspace

DISPLAY=:2 glxgears results in a segfault for me- maybe it's just a driver issue? are you usually running on an AMD card?

Pernosco trace: https://pernos.co/debug/7WwpVupHw-4kySWCKTw5xA/index.html

[lwneal]

System: Ubuntu 20.04 with nvidia GTX1080ti on nvidia-driver 470.57.02, Valve Index SteamVR 1.19.7

To repro, start Simula and in any Simula terminal window, run commands:

export LD_LIBRARY_PATH=""
glxgears

which results in the output

Segmentation fault (core dumped)

Note that DISPLAY=:1 glxgears works (but does not display the gears inside of Simula). Running glxgears or equivalently DISPLAY=:2 glxgears results in the crash.

Relevant dmesg logs:

 [349294.663963] glxgears[840113]: segfault at 0 ip 00007fc789776454 sp 00007ffc90a436e0 error 4 in libGLX_mesa.so.0.0.0[7fc789753000+44000]
 [349294.663975] Code: d0 be 58 00 00 00 bf 01 00 00 00 e8 46 e5 fd ff 49 89 c4 48 85 c0 74 b9 48 8d 35 66 36 02 00 48 89 df e8 bf db fd ff 48 89 df <f3> 0f 6f 00 49 89 5c 24 18 41 0f 11 44 24 08 e8 08 d
b fd ff ba 04
 [349314.583234] glxgears[840406]: segfault at 0 ip 00007fe1cbf34454 sp 00007ffef6bd1a70 error 4 in libGLX_mesa.so.0.0.0[7fe1cbf11000+44000]
 [349314.583245] Code: d0 be 58 00 00 00 bf 01 00 00 00 e8 46 e5 fd ff 49 89 c4 48 85 c0 74 b9 48 8d 35 66 36 02 00 48 89 df e8 bf db fd ff 48 89 df <f3> 0f 6f 00 49 89 5c 24 18 41 0f 11 44 24 08 e8 08 d
b fd ff ba 04
 [390568.739345] vrcompositor[886442]: segfault at 0 ip 00005588a9da5e06 sp 00007ffe675d4f20 error 4 in vrcompositor[5588a9cf0000+458000]
 [390568.739353] Code: 8b a3 d8 01 00 00 48 8d 83 c8 01 00 00 48 89 45 c8 49 39 c4 0f 84 da 00 00 00 4c 8d 3d 1b e8 29 00 eb 62 90 f0 41 83 45 08 01 <48> 8b 3b 48 8b 07 ff 50 18 89 c2 4c 89 f1 4c 89 fe b
f 02 00 00 00

Relevant stack trace:

ThreadStacktrace:
 .
 Thread 1 (Thread 0x7f0d5e9ce6c0 (LWP 985067)):
 #0  0x00007f0d5e98e454 in ?? () from /lib/x86_64-linux-gnu/libGLX_indirect.so.0
 No symbol table info available.
 #1  0x00007f0d5e989dd4 in ?? () from /lib/x86_64-linux-gnu/libGLX_indirect.so.0
 No symbol table info available.
 #2  0x00007f0d5e98a909 in ?? () from /lib/x86_64-linux-gnu/libGLX_indirect.so.0
 No symbol table info available.
 #3  0x000055f12201a07c in ?? ()
 No symbol table info available.
 #4  0x000055f12201857f in ?? ()
 No symbol table info available.
 #5  0x00007f0d5eb3c0b3 in __libc_start_main (main=0x55f122018410, argc=1, argv=0x7ffdf65a7ce8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdf65a7cd8) at ../csu/libc-start.c:308
         self = <optimized out>
         result = <optimized out>
         unwind_buf = {cancel_jmp_buf = {{jmp_buf = {94494146011808, 5910302350003872196, 94494146006752, 140728736578784, 0, 0, -5909162409743670844, -6044075015523196476}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x1, 0x7ffdf65a7ce8}, data = {prev = 0x0, cleanup = 0x0, canceltype = 1}}}
         not_first_call = <optimized out>
 #6  0x000055f122018f0a in ?? ()
 No symbol table info available.
Title: glxgears crashed with SIGSEGV

[georgewsinger]

Are you using other apps right now that use new gl contexts? I assume they're suffering from the same issue?

[georgewsinger]

Some learnings from the Pernosco trace:

1. WlrCompositor::handle_new_surface is called, but doesn't make it to any of the WlrXdgSurface/WlrXWaylandSurface handlers, as far as I can tell.

2. Nothing seems to be that helpful when inspecting the glxgears process: