search

floooh / cimgui-sokol-starterkit

A minimal self-contained Dear ImGui starter project for Windows, Linux and macOS.
MIT License
213 stars 19 forks source link

Hangs before window appears on Linux #6

Closed thoughton closed 3 years ago

thoughton commented 3 years ago

Hi, I've used master branch Sokol (via fips) for a while with very few issues. I only recently discovered this starterkit repo, and I decided to give it a go as it sounds like it could be useful for a new project I've been considering. However, strangely, when I've tried to build and run a clean checkout of the repo, it seems to hang before a window even appears. Breaking into it in the debugger seems to suggest it's hung on the call to _sapp.glx.QueryExtensionsString(_sapp.x11.display, _sapp.x11.screen) in _sapp_glx_init(). Do you have any thoughts on what might be happening here? Is there any additional diagnostics debugging I could turn on that might help?

Not sure if useful, but here's some gfx hardware info about my system:

$ glxinfo 
name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
GLX version: 1.4
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Mesa Intel(R) UHD Graphics 620 (KBL GT2) (0x5917)
    Version: 20.0.8
    Accelerated: yes
    Video memory: 3072MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (KBL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.8
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

And about my system:

CPU: Intel i7-8550U (8) @ 4.000GHz
GPU: Intel UHD Graphics 620
Resolution: 1920x1080
OS: Ubuntu 20.04.1 LTS x86_64
Kernel: 5.4.0-54-generic
Shell: bash 5.0.17
DE: GNOME 3.36.4
WM: Mutter

Thanks!

floooh commented 3 years ago

Hi, thanks for the bug report. The only thing that comes to mind is a missing -pthread flag, see here: https://github.com/floooh/sokol/issues/404

I've been testing on my Ubuntu 20.04 machine where the demo works, so I didn't pay attention to this flag. I just committed a potential fix which adds the -pthread flag when compiling on Linux. Can you check if this works for you?

https://github.com/floooh/cimgui-sokol-starterkit/commit/691487bbf1ace9755f854ccfd76374bffa63c23b

thoughton commented 3 years ago

Hi @floooh - thanks a lot for the fast reply. Unfortunately though, the pthread change does not seem to have helped the issue.

Here's the full callstack of when I break into it whilst it's seemingly hung:

(gdb) bt
#0  0x00007f0df44f1587 in pthread_cond_broadcast@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007f0df51ddd8b in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2  0x00007f0df51d3b8a in XQueryExtension () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3  0x00007f0df51c71c7 in XInitExtension () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4  0x00007f0df48039d1 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
#5  0x00007f0df47ff654 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
#6  0x00007f0df47ffbf2 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
#7  0x000055b15d4e83da in _sapp_glx_init ()
#8  0x000055b15d4eafd8 in _sapp_linux_run ()
#9  0x000055b15d4eb1b2 in main ()
floooh commented 3 years ago

Hmm strange that -pthread doesn't help. Your callstack is exactly the same as in this issue (the symptom there is also a hang, unlike that other issue I linked which crashed, but both were fixed with -pthread):

https://github.com/floooh/sokol/issues/376

floooh commented 3 years ago

...can you do these steps, and post the terminal output? I just want to make sure that the -pthread is actually showing.

First, delete the build subdirectory if it exists, and then:

mkdir build && cd build
cmake ..
make VERBOSE=1

Thanks!

floooh commented 3 years ago

...maybe the issue is caused because some parts (namely imgui) are still compiled without -pthread... let me try something else (I really don't understand why GCC isn't setting this flag by default, it's causing so much hassle...).

floooh commented 3 years ago

Ok new attempt in those two commits:

5da3b0c9c1d888deb87b810e53d3d2385cfd897b

9ee80f8e247a699cf2be79b5d50517964a3ee4cb

This sets up the pthread stuff using CMake's builtin module via find_package(), hopefully this should fix those issues. I don't understand why I'm not seeing those problems here, I just checked again and I have a vanilla Ubuntu 20.04 with X11 desktop (e.g. no X11 on Wayland or similar).

floooh commented 3 years ago

...however, the "recommeneded" cmake way doesn't add the -pthread flag to all compiler invocations either, so if the above fix doesn't work, the next step would be to simply add -pthread to the global C, CXX and LINKER options like I do in fips (which seems to work, but is rather brute-force):

https://github.com/floooh/fips/blob/c008c70f6b970990f7753aa0877222c218b1fd18/cmake-toolchains/linux.cmake#L25-L37

thoughton commented 3 years ago

Thanks @floooh - those latest changes seem to have done the trick!

The only additional thing to note now is I noticed I get an assertion fail when closing the window:

$ ./demo
demo: tpp.c:82: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= fifo_min_prio && new_prio <= fifo_max_prio)' failed.
Aborted (core dumped)

Or, in the debugger:

(gdb) bt
#0  0x00007fe8a657e18b in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fe8a655d859 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007fe8a655d729 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007fe8a656ef36 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007fe8a5e7b179 in __pthread_tpp_change_priority () from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007fe8a5e70b09 in __pthread_mutex_lock_full () from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x00007fe8a6b6b5bb in XrmDestroyDatabase () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007fe8a6b52225 in _XFreeDisplayStructure () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8  0x00007fe8a6b3f3c1 in XCloseDisplay () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9  0x000055f74f0c113e in _sapp_linux_run ()
#10 0x000055f74f0c11b2 in main ()

(Am happy to open this in a new issue though if you prefer?)

Thanks again!

floooh commented 3 years ago

I think the assertion you're getting now on shutdown is the same problem, so no need to create a new ticket. I'll try the "brute force" variant next, globally setting the -pthread flag for all compiler and linker invocations (so the same thing that fips does).

floooh commented 3 years ago

Ok new attempt:

https://github.com/floooh/cimgui-sokol-starterkit/commit/e4014badd4fd9939cae80f5597cec7ce53d70068

If this still shows any sort of problems then it must be something else.

thoughton commented 3 years ago

Hi @floooh - unfortunately with that latest change it's now back to hanging before a window appears...

Here's the verbose make output in case it holds any clues:

/.linuxbrew/Cellar/cmake/3.19.1/bin/cmake -S/github/cimgui-sokol-starterkit -B/github/cimgui-sokol-starterkit/build --check-build-system CMakeFiles/Makefile.cmake 0
/.linuxbrew/Cellar/cmake/3.19.1/bin/cmake -E cmake_progress_start /github/cimgui-sokol-starterkit/build/CMakeFiles /github/cimgui-sokol-starterkit/build//CMakeFiles/progress.marks
make  -f CMakeFiles/Makefile2 all
make[1]: Entering directory '/github/cimgui-sokol-starterkit/build'
make  -f CMakeFiles/cimgui.dir/build.make CMakeFiles/cimgui.dir/depend
make[2]: Entering directory '/github/cimgui-sokol-starterkit/build'
cd /github/cimgui-sokol-starterkit/build && /.linuxbrew/Cellar/cmake/3.19.1/bin/cmake -E cmake_depends "Unix Makefiles" /github/cimgui-sokol-starterkit /github/cimgui-sokol-starterkit /github/cimgui-sokol-starterkit/build /github/cimgui-sokol-starterkit/build /github/cimgui-sokol-starterkit/build/CMakeFiles/cimgui.dir/DependInfo.cmake --color=
Dependee "/github/cimgui-sokol-starterkit/build/CMakeFiles/cimgui.dir/DependInfo.cmake" is newer than depender "/github/cimgui-sokol-starterkit/build/CMakeFiles/cimgui.dir/depend.internal".
Dependee "/github/cimgui-sokol-starterkit/build/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/github/cimgui-sokol-starterkit/build/CMakeFiles/cimgui.dir/depend.internal".
Scanning dependencies of target cimgui
make[2]: Leaving directory '/github/cimgui-sokol-starterkit/build'
make  -f CMakeFiles/cimgui.dir/build.make CMakeFiles/cimgui.dir/build
make[2]: Entering directory '/github/cimgui-sokol-starterkit/build'
[ 10%] Building CXX object CMakeFiles/cimgui.dir/cimgui/cimgui.cpp.o
/usr/bin/g++   -pthread -std=gnu++11 -o CMakeFiles/cimgui.dir/cimgui/cimgui.cpp.o -c /github/cimgui-sokol-starterkit/cimgui/cimgui.cpp
[ 20%] Building CXX object CMakeFiles/cimgui.dir/cimgui/imgui/imgui.cpp.o
/usr/bin/g++   -pthread -std=gnu++11 -o CMakeFiles/cimgui.dir/cimgui/imgui/imgui.cpp.o -c /github/cimgui-sokol-starterkit/cimgui/imgui/imgui.cpp
[ 30%] Building CXX object CMakeFiles/cimgui.dir/cimgui/imgui/imgui_widgets.cpp.o
/usr/bin/g++   -pthread -std=gnu++11 -o CMakeFiles/cimgui.dir/cimgui/imgui/imgui_widgets.cpp.o -c /github/cimgui-sokol-starterkit/cimgui/imgui/imgui_widgets.cpp
[ 40%] Building CXX object CMakeFiles/cimgui.dir/cimgui/imgui/imgui_draw.cpp.o
/usr/bin/g++   -pthread -std=gnu++11 -o CMakeFiles/cimgui.dir/cimgui/imgui/imgui_draw.cpp.o -c /github/cimgui-sokol-starterkit/cimgui/imgui/imgui_draw.cpp
[ 50%] Building CXX object CMakeFiles/cimgui.dir/cimgui/imgui/imgui_demo.cpp.o
/usr/bin/g++   -pthread -std=gnu++11 -o CMakeFiles/cimgui.dir/cimgui/imgui/imgui_demo.cpp.o -c /github/cimgui-sokol-starterkit/cimgui/imgui/imgui_demo.cpp
[ 60%] Linking CXX static library libcimgui.a
/.linuxbrew/Cellar/cmake/3.19.1/bin/cmake -P CMakeFiles/cimgui.dir/cmake_clean_target.cmake
/.linuxbrew/Cellar/cmake/3.19.1/bin/cmake -E cmake_link_script CMakeFiles/cimgui.dir/link.txt --verbose=1
/usr/bin/ar qc libcimgui.a CMakeFiles/cimgui.dir/cimgui/cimgui.cpp.o CMakeFiles/cimgui.dir/cimgui/imgui/imgui.cpp.o CMakeFiles/cimgui.dir/cimgui/imgui/imgui_widgets.cpp.o CMakeFiles/cimgui.dir/cimgui/imgui/imgui_draw.cpp.o CMakeFiles/cimgui.dir/cimgui/imgui/imgui_demo.cpp.o
/usr/bin/ranlib libcimgui.a
make[2]: Leaving directory '/github/cimgui-sokol-starterkit/build'
[ 60%] Built target cimgui
make  -f CMakeFiles/sokol.dir/build.make CMakeFiles/sokol.dir/depend
make[2]: Entering directory '/github/cimgui-sokol-starterkit/build'
cd /github/cimgui-sokol-starterkit/build && /.linuxbrew/Cellar/cmake/3.19.1/bin/cmake -E cmake_depends "Unix Makefiles" /github/cimgui-sokol-starterkit /github/cimgui-sokol-starterkit /github/cimgui-sokol-starterkit/build /github/cimgui-sokol-starterkit/build /github/cimgui-sokol-starterkit/build/CMakeFiles/sokol.dir/DependInfo.cmake --color=
Dependee "/github/cimgui-sokol-starterkit/build/CMakeFiles/sokol.dir/DependInfo.cmake" is newer than depender "/github/cimgui-sokol-starterkit/build/CMakeFiles/sokol.dir/depend.internal".
Dependee "/github/cimgui-sokol-starterkit/build/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/github/cimgui-sokol-starterkit/build/CMakeFiles/sokol.dir/depend.internal".
Scanning dependencies of target sokol
make[2]: Leaving directory '/github/cimgui-sokol-starterkit/build'
make  -f CMakeFiles/sokol.dir/build.make CMakeFiles/sokol.dir/build
make[2]: Entering directory '/github/cimgui-sokol-starterkit/build'
[ 70%] Building C object CMakeFiles/sokol.dir/sokol/sokol.c.o
/usr/bin/gcc  -I/github/cimgui-sokol-starterkit/cimgui -I/.linuxbrew/include -I/include-shims -I/.linuxbrew/include -I/include-shims -pthread -std=gnu11 -o CMakeFiles/sokol.dir/sokol/sokol.c.o -c /github/cimgui-sokol-starterkit/sokol/sokol.c
[ 80%] Linking CXX static library libsokol.a
/.linuxbrew/Cellar/cmake/3.19.1/bin/cmake -P CMakeFiles/sokol.dir/cmake_clean_target.cmake
/.linuxbrew/Cellar/cmake/3.19.1/bin/cmake -E cmake_link_script CMakeFiles/sokol.dir/link.txt --verbose=1
/usr/bin/ar qc libsokol.a CMakeFiles/sokol.dir/sokol/sokol.c.o
/usr/bin/ranlib libsokol.a
make[2]: Leaving directory '/github/cimgui-sokol-starterkit/build'
[ 80%] Built target sokol
make  -f CMakeFiles/demo.dir/build.make CMakeFiles/demo.dir/depend
make[2]: Entering directory '/github/cimgui-sokol-starterkit/build'
cd /github/cimgui-sokol-starterkit/build && /.linuxbrew/Cellar/cmake/3.19.1/bin/cmake -E cmake_depends "Unix Makefiles" /github/cimgui-sokol-starterkit /github/cimgui-sokol-starterkit /github/cimgui-sokol-starterkit/build /github/cimgui-sokol-starterkit/build /github/cimgui-sokol-starterkit/build/CMakeFiles/demo.dir/DependInfo.cmake --color=
Dependee "/github/cimgui-sokol-starterkit/build/CMakeFiles/demo.dir/DependInfo.cmake" is newer than depender "/github/cimgui-sokol-starterkit/build/CMakeFiles/demo.dir/depend.internal".
Dependee "/github/cimgui-sokol-starterkit/build/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/github/cimgui-sokol-starterkit/build/CMakeFiles/demo.dir/depend.internal".
Scanning dependencies of target demo
make[2]: Leaving directory '/github/cimgui-sokol-starterkit/build'
make  -f CMakeFiles/demo.dir/build.make CMakeFiles/demo.dir/build
make[2]: Entering directory '/github/cimgui-sokol-starterkit/build'
[ 90%] Building C object CMakeFiles/demo.dir/demo.c.o
/usr/bin/gcc  -I/github/cimgui-sokol-starterkit/sokol -I/github/cimgui-sokol-starterkit/cimgui -I/.linuxbrew/include -I/include-shims -I/.linuxbrew/include -I/include-shims -pthread -std=gnu11 -o CMakeFiles/demo.dir/demo.c.o -c /github/cimgui-sokol-starterkit/demo.c
[100%] Linking C executable demo
/.linuxbrew/Cellar/cmake/3.19.1/bin/cmake -E cmake_link_script CMakeFiles/demo.dir/link.txt --verbose=1
/usr/bin/gcc -I/.linuxbrew/include -I/include-shims -I/.linuxbrew/include -I/include-shims -pthread -L/.linuxbrew/lib -pthread -rdynamic CMakeFiles/demo.dir/demo.c.o -o demo  libsokol.a -lX11 -lXi -lXcursor -lGL -ldl -lm libcimgui.a -lstdc++ -lm 
make[2]: Leaving directory '/github/cimgui-sokol-starterkit/build'
[100%] Built target demo
make[1]: Leaving directory '/github/cimgui-sokol-starterkit/build'
/.linuxbrew/Cellar/cmake/3.19.1/bin/cmake -E cmake_progress_start /github/cimgui-sokol-starterkit/build/CMakeFiles 0
floooh commented 3 years ago

it's now back to hanging before a window appears

...wow ok, that's unexpected (because according to the log the -pthread flag is now passed to all gcc/g++ invocations.

Could you do a verbose log of the previous commit that worked but crashed on shutdown? I wonder how the compile flags look there (this contains more "cmake magic" for setting the pthreads flags):

git checkout cbbeb616bccfbafd12c357c3cd247c8ed0acbbe7
mkdir build && cd build
cmake ..
make VERBOSE=1

...afterwards leave detached head state with 'git checkout main'.

Thanks

thoughton commented 3 years ago

Hey @floooh - I'm starting to worry that I might just be wasting your time... I'm beginning to suspect there's just something wrong with my system config somehow. Because now, with HEAD detached at cbbeb61, I'm still getting the hang before the window - even though previously that commit definitely did work (albeit with the assert on exit).

So there must be something else going on here, right? And I feel bad about taking up any more of your time with it, especially if it's increasingly looking like some iffy config at my end.

I'm going to continue my investigations though, and will report back. Next step: I'm going to create a fresh new user on the system, to see whether they have more success.

However, one thing I can still say with pretty much 100% confidence, is that it's still true that I do not recall ever experiencing these types of issues with "main branch" Sokol - but maybe that just proves how neat fips is? :)

thoughton commented 3 years ago

So, my experiment with the new user worked: the HEAD revision works fine, the detached cbbeb61 works fine, and neither of them assert on exit.

The key difference between the resulting binaries from the two users is that for some reason my main user's binary does not get libpthread linked:

    linux-vdso.so.1 (0x00007ffdce393000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007ffac3613000)
    libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007ffac3601000)
    libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007ffac35f4000)
    libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007ffac356c000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffac3566000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ffac3385000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffac3234000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffac3219000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffac3027000)
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007ffac2ffd000)
    libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007ffac2fe8000)
    libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007ffac2dde000)
    libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007ffac2dd4000)
    libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007ffac2d1c000)
    libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007ffac2ce8000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ffac38bc000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007ffac2ce2000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007ffac2cda000)
    libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0 (0x00007ffac2cbe000)

Whereas my test user gets all of the above linked, and also this:

libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0

This is clearly the missing link, so now I'm just trying to work out why my main user does not get this linked into its binary.

I've been diffing the verbose output for each and they're both actually very similar, but the most suspicious difference at the moment is that my main user does pass a few additional default library and header include paths to each compiler and linker invocation... So next I will try to remove those and see if that makes a difference.

thoughton commented 3 years ago

Ok - very embarrassingly, this was due to me having a custom export LDFLAGS="-L..." in my .profile to setup some common library paths. Reading around the internet it looks like this is a very bad idea for a number of reasons; and indeed, it seems to be the reason why it was failing to link libpthread here (why only libpthread failed to be found, and why it failed silently, I'm really not sure, but maybe I'll try looking into that another day).

I'm really very sorry for taking up your time with this. Thanks for your help, and thanks for the awesome library.

floooh commented 3 years ago

Ah alright, no worries! Interesting that this is the second time recently where I've seen global environment variables messing up builds :)

(last time the culprit was the CPATH environment variable which messed up cross-compilation builds:

https://groups.google.com/g/emscripten-discuss/c/2Ot0ZQoK9is

thoughton commented 3 years ago

Oh that is interesting! Because after reading around a bit I thought CPATH was what I was actually supposed to be using instead of setting a default CFLAGS for common include paths (which I'm also doing)... Oh well, I think I had better avoid that one too then. :)

Thanks for your patience and understanding!

One final thought: is it worth reverting this repo to the earlier, less "brute force" method of handling pthreads now, or do you think it's ok to keep it as it is?

floooh commented 3 years ago

One final thought: is it worth reverting this repo to the earlier, less "brute force" method of handling pthreads now, or do you think it's ok to keep it as it is?

Good point, I think I'll revert it to the find_package() version, as that should be the most "cmake-ish" way.

thoughton commented 3 years ago

I just gave it a quick check on my setup and it all seems to be working - thanks! :+1: