Unix port failing on sdl_display object creation

[androiddrew]

So I have attempted to build the unix port on two ubuntu machines. One is a 22.04 with an Nvidia GPU the other is a 24.04 Ubuntu machine with a simple dell with an onboard GPU.

I have added DEBUG to the micropython compile with:

diff --git a/builder/unix.py b/builder/unix.py
index ba0bc7d..669798f 100644
--- a/builder/unix.py
+++ b/builder/unix.py
@@ -245,6 +245,7 @@ def compile(*args):  # NOQA
 
     cmd_ = compile_cmd[:]
     cmd_.extend(list(args))
+    cmd_.insert(0, "DEBUG=1")
 
     return_code, _ = spawn(cmd_)
     if return_code != 0:

I am running on both machines

python3 make.py unix submodules clean mpy_cross DISPLAY=sdl_display INDEV=sdl_pointer

I copy the example program on https://github.com/lvgl-micropython/lvgl_micropython/blob/main/README.md?plain=1#L580-L628 to a test_unix_sdl.py file then run

toor@toor-jammy-jellifish:~/experiments/lvgl_micropython$ ./build/lvgl_micropy_unix ./test_unix_sdl.py
Segmentation fault (core dumped)

When I run the program with gdb

Reading symbols from ./build/lvgl_micropy_unix...
(gdb) break main
Breakpoint 1 at 0x1b1f48: file main.c, line 467.
(gdb) run ./test_unix_sdl.py 
Starting program: /home/toor/experiments/lvgl_micropython/build/lvgl_micropy_unix ./test_unix_sdl.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=2, argv=0x7fffffffdb58) at main.c:467
467	int main(int argc, char **argv) {
(gdb) c
Continuing.
[New Thread 0x7ffff1200640 (LWP 24564)]

Thread 1 "lvgl_micropy_un" received signal SIG34, Real-time event 34.
0x00007ffff7d18bcf in __GI___poll (fds=0x7fffffffd248, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29	../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) backtrace
#0  0x00007ffff7d18bcf in __GI___poll (fds=0x7fffffffd248, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007ffff6f647e2 in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007ffff6f64eb1 in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007ffff6f65ea6 in xcb_wait_for_reply64 () from /lib/x86_64-linux-gnu/libxcb.so.1
#4  0x00007ffff6fc831c in _XReply () from /lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007ffff66c4921 in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#6  0x00007ffff667382c in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#7  0x00007ffff4e088fe in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#8  0x00007ffff667144d in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#9  0x00007ffff4e5e564 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#10 0x00007ffff4e62d5e in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#11 0x00007ffff4e62ee6 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#12 0x00007ffff4e3858b in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#13 0x00007ffff4e48875 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#14 0x00007ffff666f7c7 in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#15 0x00007ffff666feef in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#16 0x00007ffff7ffd040 in ?? () from /lib64/ld-linux-x86-64.so.2
#17 0x0000000000000000 in ?? ()

The above output was from my 22.04 ubuntu machine with an NVIDIA GPU.

I am getting this signal 34 event. I'm kind of at a loss where to take this. I manually typed in each line from test_unix_sdl.py and I believe it is happening on initializing the SDLDisplay.

display = sdl_display.SDLDisplay(
    data_bus=bus,
    display_width=_WIDTH,
    display_height=_HEIGHT,
    frame_buffer1=buf1,
    frame_buffer2=buf2,
    color_space=lv.COLOR_FORMAT.RGB888
)

[androiddrew]

Ok, this is interesting so I

sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p
sudo systemctl stop apport
ulimit -c unlimited
sudo sysctl -p

And reran the program, hitting the segmentation fault which gave me a core dump

gdb ./build/lvgl_micropy_unix /tmp/core-LVGL_MP_RENDERE.29778

And I see a different backtrace

(gdb) backtrace
#0  0x00005cf37db3a12d in gc_lock () at ../../py/gc.c:337
#1  0x00005cf37dbb8c51 in call_py_func_with_lock (cif=0x7f1ab9d021a8, ret=<optimized out>, args=0x7f1ab3bfee60, user_data=<optimized out>) at modffi.c:295
#2  0x00007f1aba8e77ec in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#3  0x00007f1aba8e8050 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#4  <signal handler called>
#5  0x00005cf37dcbcbd0 in BlitNtoNPixelAlpha ()
#6  0x00005cf37dcad056 in SDL_SoftBlit ()
#7  0x00005cf37dc21f04 in SDL_UpperBlit_REAL ()
#8  0x00005cf37dc0cc24 in SW_RunCommandQueue ()
#9  0x00005cf37dbf93cd in SDL_RenderPresent_REAL ()
#10 0x00005cf37da9c014 in flush_thread (self_in=0x7f1ab9c18300) at /home/toor/experiments/lvgl_micropython/ext_mod/lcd_bus/sdl_bus/sdl_bus.c:233
#11 0x00005cf37dc15e3a in SDL_RunThread ()
#12 0x00005cf37dc6b6bd in RunThread ()
#13 0x00007f1aba694ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#14 0x00007f1aba726850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) 

And it looks like garbage collection may be doing something here.

So I added

import gc
gc.disable()

But still see

#0  0x00005cb61d50112d in gc_lock () at ../../py/gc.c:337
337	    MP_STATE_THREAD(gc_lock_depth)++;
[Current thread is 1 (Thread 0x722ef7200640 (LWP 30302))]
(gdb) backtrace
#0  0x00005cb61d50112d in gc_lock () at ../../py/gc.c:337
#1  0x00005cb61d57fc51 in call_py_func_with_lock (cif=0x722efd302268, ret=<optimized out>, args=0x722ef71fede0, user_data=<optimized out>) at modffi.c:295
#2  0x0000722efdf2f7ec in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#3  0x0000722efdf30050 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#4  <signal handler called>
#5  0x0000722efadff1bd in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#6  0x0000722efc78a11e in __glDispatchCheckMultithreaded () from /lib/x86_64-linux-gnu/libGLdispatch.so.0
#7  0x0000722efcec0e8c in ?? () from /lib/x86_64-linux-gnu/libGLX.so.0
#8  0x00005cb61d6c6c91 in X11_GL_MakeCurrent ()
#9  0x00005cb61d5f2ba8 in SDL_GL_MakeCurrent_REAL ()
#10 0x00005cb61d5c201a in GL_ActivateRenderer ()
#11 0x00005cb61d5c4de1 in GL_UpdateTexture ()
#12 0x00005cb61d5b7477 in SDL_UpdateTexture_REAL ()
#13 0x00005cb61d5eecd1 in SDL_UpdateWindowTexture ()
#14 0x00005cb61d5ef971 in SDL_UpdateWindowSurface_REAL ()
#15 0x00005cb61d5c042d in SDL_RenderPresent_REAL ()
#16 0x00005cb61d463014 in flush_thread (self_in=0x722efd218380) at /home/toor/experiments/lvgl_micropython/ext_mod/lcd_bus/sdl_bus/sdl_bus.c:233
#17 0x00005cb61d5dce3a in SDL_RunThread ()
#18 0x00005cb61d6326bd in RunThread ()
#19 0x0000722efdc94ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#20 0x0000722efdd26850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

[kdschlosser]

wow DUH!!! (this is DUH about me not you)

OK so here is the skinny. MicroPython is exiting before the code gets the chance to fully run. When you run the file directly as you are there is no loop in the main thread to keep the program running. This is normally handled by the repl.

take your test script and place it into the same folder that the MicroPython binary is in. Then run the binary without adding the file name onto the end. MicroPython will run and you will get a REPL. then simply import the file. import test_unix_sdl and away you go....

[kdschlosser]

I have been trying to figure out why the backtrace is the way it is as it wasn't making any sense to me either.

[kdschlosser]

what I did to improve the performance is I created a thread that handles the flushing of the buffers to the screen. That is seen here

#17 0x00005cb61d5dce3a in SDL_RunThread ()

this line is a bit misleading...

#0  0x00005cb61d50112d in gc_lock () at ../../py/gc.c:337

line 337 is NOT gc_lock() look carefully. It says "in" gc_lock()

Here is gc_lock

void gc_lock(void) {
    // This does not need to be atomic or have the GC mutex because:
    // - each thread has its own gc_lock_depth so there are no races between threads;
    // - a hard interrupt will only change gc_lock_depth during its execution, and
    //   upon return will restore the value of gc_lock_depth.
    MP_STATE_THREAD(gc_lock_depth)++;                                                         <<<=== line 337
}

line 337 is actually a macro and that macro translates to...

mp_thread_get_state()->gc_lock_depth

The failure is happening not with the gc but is happening from mp_thread_get_state()

[androiddrew]

Ah, import test_unix_sdl still seg faults, but I assume that's because of what you are mentioning later with the mp_thread_get_state() call. I unfortunately have blown past what I know already on this one, I can recreate it on another machine so it's not specific to the nvidia glx stuff that I initially thought it was.

[kdschlosser]

OK that's the important part is it not being specific to the display driver..

when you do a debug run on it does it still seg fault at the same place?

[kdschlosser]

also have you tried increasing the heap to say 20mb, just for shits and giggles.. Ya never know...

[androiddrew]

OK that's the important part is it not being specific to the display driver..

when you do a debug run on it does it still seg fault at the same place?

No the core dump seems to show a different backtrace. The first gdb trace I provide is from a gdb run.

also have you tried increasing the heap to say 20mb, just for shits and giggles.. Ya never know...

Set heap size to 20MB. Still seg faults. but this is the core-dump backtrace

Reading symbols from ./build/lvgl_micropy_unix...

warning: Can't open file /memfd:/.nvidia_drv.XXXXXX (deleted) during file-backed mapping note processing
[New LWP 65653]
[New LWP 65657]

warning: Section `.reg-xstate/65653' in core file too small.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./build/lvgl_micropy_unix ./test_unix_sdl.py'.
Program terminated with signal SIGSEGV, Segmentation fault.

warning: Section `.reg-xstate/65653' in core file too small.
#0  0x0000761e5b97b686 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
[Current thread is 1 (Thread 0x761e5b972b80 (LWP 65653))]
(gdb) backtrace
#0  0x0000761e5b97b686 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#1  0x0000761e5b97c050 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#2  <signal handler called>
#3  __GI___ioctl (fd=9, request=3223340586) at ../sysdeps/unix/sysv/linux/ioctl.c:36
#4  0x0000761e58d27140 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#5  0x0000761e58d2d84d in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#6  0x0000761e588603c0 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#7  0x0000761e58861452 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#8  0x0000761e58862ee6 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#9  0x0000761e5883858b in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#10 0x0000761e58848875 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#11 0x0000761e5a12c7c7 in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#12 0x0000761e5a12ceef in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#13 0x0000761e5bace040 in ?? () from /lib64/ld-linux-x86-64.so.2
#14 0x0000000000000000 in ?? ()

Back to Nvidia stuff

[androiddrew]

😭 I created an Ubuntu VM on my macbook using VMWare....same seg fault.

[androiddrew]

Ok on the VM (Ubuntu 22.04) I get this issue

Thread 1 "lvgl_micropy_un" received signal SIG34, Real-time event 34.
Download failed: Invalid argument.  Continuing without source file build-llvm/tools/clang/stage2-bins/llvm/include/llvm/PassInfo.h.
~PassInfo () at llvm/include/llvm/PassInfo.h:30
warning: 30	llvm/include/llvm/PassInfo.h: No such file or directory
(gdb) quit
A debugging session is active.

Which seems so much more sparse than the other sessions...and wI have no clue why llvm is even needed

[kdschlosser]

The core dump file is truncated.. see here as to possible causes..

https://stackoverflow.com/questions/47047779/why-does-gdb-prompt-unexpected-size-of-section-reg-xstate-xxxxx-in-core-file

It's a gdb thing that needs to be corrected so we can see the proper dump output.

warning: Section `.reg-xstate/65653' in core file too small.

[kdschlosser]

I just cloned the repo, compiled it and ran it...

it's running and not crashing.

Did you guys installed the requirements?

sudo apt-get install build-essential libffi-dev pkg-config cmake ninja-build gnome-desktop-testing libasound2-dev libpulse-dev  libaudio-dev libjack-dev libsndio-dev libx11-dev libxext-dev libxrandr-dev libxcursor-dev libxfixes-dev libxi-dev libxss-dev libxkbcommon-dev libdrm-dev libgbm-dev libgl1-mesa-dev libgles2-mesa-dev libegl1-mesa-dev libdbus-1-dev libibus-1.0-dev libudev-dev fcitx-libs-dev libpipewire-0.3-dev libwayland-dev libdecor-0-dev

On top of those you also need to have a desktop GUI installed and running. There needs to be a framework in place that SDL is able to use to display the application window. It will not work from the native shell. You MUST launch the desktop and then open a shell once in the desktop the GUI has to be running.

[androiddrew]

• Yup I have all the dependencies installed as documented
• All desktop machines have a GUI and I'm running it in a desktop environment.

I see a flash of the window open, it's black but no slider widget is displayed then it seg faults. That occurs in all three of my machines two of which are new installs of 24.04 Ubuntu on both a Dell intel i7 machine and a VM fusion VM. The third one is a Ryzen + Nvidia desktop which is where we see all the desk

Are you running the same compilation command as I am? What OS are you using? What virtual machine software?

[androiddrew]

Got the VM to drop a core dump

sing host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./build/lvgl_micropy_unix'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000058fa86825e5d in gc_lock () at ../../py/gc.c:337
337	    MP_STATE_THREAD(gc_lock_depth)++;
[Current thread is 1 (Thread 0x769b25e006c0 (LWP 24963))]
(gdb) backtrace
#0  0x000058fa86825e5d in gc_lock () at ../../py/gc.c:337
#1  0x000058fa868a3fd1 in call_py_func_with_lock (cif=0x769b34702028, ret=<optimized out>, args=0x769b25dff560, user_data=<optimized out>)
    at modffi.c:295
#2  0x0000769b352ba641 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#3  0x0000769b352bad38 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#4  <signal handler called>
#5  0x000058fa869036bf in SDL_FillRect4SSE ()
#6  0x000058fa86903967 in SDL_FillRect_REAL ()
#7  0x000058fa868f5543 in SW_RunCommandQueue ()
#8  0x000058fa868e3e3d in SDL_RenderPresent_REAL ()
#9  0x000058fa8679cd19 in flush_thread (self_in=0x769b34618520) at /home/toor/workspace/lvgl_micropython/ext_mod/lcd_bus/sdl_bus/sdl_bus.c:233
#10 0x000058fa869007ea in SDL_RunThread ()
#11 0x000058fa8695b9ed in RunThread ()
#12 0x0000769b3509ca94 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#13 0x0000769b35129c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

[mdlayher]

I gave the example a try on Ubuntu 22.04.4 with GNOME and Wayland and I don't get a segfault, but I do end up with an empty window with no UI elements: