Problem with dirty close in scenic

After temporary solved my first problem with scenic I need a community help to fix second problem. I have installed scenic_new archive, created project, compiled and started. The only problem I have is:

<logger time here> [error] dirty close

I have looked at source code and I have found that it comes from scenic_driver_glfw dependency in file deps/scenic_driver_glfw/lib/glfw.ex (debugged at line 178) which means that glfw driver is nicely handling exit error which comes to driver GenServer, but unfortunately I have not much helpful information even if I comment it. After placing some comments I have received log with this error:

<logger time here> [error] Scenic.ViewPort.Driver :glfw received unexpected message in handle_info/2: {:EXIT, #Port<0.786>, :normal}

In README.md file I have found 3 requirements glew, glfw (in version 3) and pkgconfig. I have checked it in my Funtoo Linux distribution and here is what I have there:

[ebuild   R    ] media-libs/glew-2.1.0:0/2.1::media-kit  USE="-doc -static-libs" ABI_X86="(64) -32 (-x32)" 747 KiB
[ebuild   R    ] media-libs/glfw-3.2.1::media-kit  USE="wayland -examples" 640 KiB                                
[ebuild   R    ] virtual/pkgconfig-0-r1::core-kit  ABI_X86="(64) -32 (-x32)" 0 KiB

I have also checked if my OpenGL is already working.

Here is my current OpenGL configuration:

$ eselect opengl list
Available OpenGL implementations:
  [1]   xorg-x11 *

And here is what lots of people (with topics about graphic driver problems) ask i.e. direct rendering:

$ glxinfo | grep direct
direct rendering: Yes
    GL_ARB_depth_clamp, GL_ARB_derivative_control, GL_ARB_direct_state_access, 
    GL_ARB_draw_elements_base_vertex, GL_ARB_draw_indirect, 
    GL_ARB_map_buffer_range, GL_ARB_multi_bind, GL_ARB_multi_draw_indirect,

It would be awesome if somebody could help me. @boydm maybe you have any ideas how it could be solved?

fishing here… but noticed wayland here:

so maybe the install instructions in this PR are relevant? https://github.com/boydm/scenic/pull/21/commits/1807638bff55c46d75aa192757387ba8689de0de

eg

If you’re using wayland, you’ll probably need glfw-wayland instead of glfw-x11 and glew-wayland instead of glew

1 Like

@outlog: For now I’m not using Wayland, because Plasma 5 does not have yet full support for it. Also I have compiled support for Wayland, but OpenGL was tested under X11.

1 Like

I don’t have any experience with Funtoo. I’ve gotten it working on Ubuntu and others have just gotten ArchLinux and Fedora working.

One note: when I put the scenic_math library up, i included the *.o files, which I shouldn’t have done. That’s been fixed Try updating that package, although I don’t think it will solve your issue.

1 Like

At start of post I wrote:

so it’s not a problem with *.o files in scenic_math. I think that this problem is related to scenic_driver_glfw.

I probably found a problem of this error. It happens in file deps/scenic_driver_glfw/lib/glfw.ex at line 83 when opening port.

Process.flag(:trap_exit, true)
executable = :code.priv_dir(:scenic_driver_glfw) ++ @port ++ port_args
port = Port.open({:spawn, executable}, [:binary, {:packet, 4}])

In my case the executable is:

_build/dev/lib/scenic_driver_glfw/priv/prod/scenic_driver_glfw 700 600 “scenic example” false 128

which comes from default untouched configuration (I have just added one line to debug it).

Was curious why it’s not working. I have tried to execute this command manually. Unfortunately I have not received any messages. However I found that return code instead of successful 0 is set to 255. I did not took a look at c_src yet, but I have checked this executable.

It compiles without problem and here is output of ldd command:

linux-vdso.so.1 (0x00007fff169d6000)                                             
libglfw.so.3 => /usr/lib64/libglfw.so.3 (0x00007fcd4f37f000)                            
librt.so.1 => /lib64/librt.so.1 (0x00007fcd4f177000)                                    
libm.so.6 => /lib64/libm.so.6 (0x00007fcd4ee74000)                                              
libdl.so.2 => /lib64/libdl.so.2 (0x00007fcd4ec70000)                                                      
libwayland-egl.so.1 => /usr/lib64/libwayland-egl.so.1 (0x00007fcd4ea6e000)                                
libwayland-client.so.0 => /usr/lib64/libwayland-client.so.0 (0x00007fcd4e85f000)
libxkbcommon.so.0 => /usr/lib64/libxkbcommon.so.0 (0x00007fcd4e620000)
libGLEW.so.2.1 => /usr/lib64/libGLEW.so.2.1 (0x00007fcd4e380000)
libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007fcd4e101000)
libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007fcd4de98000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcd4dc7c000)
libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007fcd4da6b000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fcd4d731000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fcd4d50c000)
libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007fcd4d309000)
libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007fcd4d103000)
libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00007fcd4cf01000)
libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00007fcd4cce8000)
libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00007fcd4cae3000)
libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007fcd4c8dd000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fcd4c6cb000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fcd4c4c7000)
libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fcd4c2c1000)
libc.so.6 => /lib64/libc.so.6 (0x00007fcd4bf2a000)
libwayland-cursor.so.0 => /usr/lib64/libwayland-cursor.so.0 (0x00007fcd4bd22000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcd4f594000)
libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007fcd4bb1a000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libstdc++.so.6 (0x00007fcd4b7a0000)
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgcc_s.so.1 (0x00007fcd4b589000)
libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fcd4b360000)
libxcb-dri3.so.0 => /usr/lib64/libxcb-dri3.so.0 (0x00007fcd4b15d000)
libxcb-xfixes.so.0 => /usr/lib64/libxcb-xfixes.so.0 (0x00007fcd4af55000)
libxcb-present.so.0 => /usr/lib64/libxcb-present.so.0 (0x00007fcd4ad52000)
libxcb-sync.so.1 => /usr/lib64/libxcb-sync.so.1 (0x00007fcd4ab4b000)
libxshmfence.so.1 => /usr/lib64/libxshmfence.so.1 (0x00007fcd4a949000)
libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00007fcd4a719000)
libbsd.so.0 => /usr/lib64/libbsd.so.0 (0x00007fcd4a504000)

As I have already said I’m not under any Wayland session. I’m in full X11 session.

Are that information helpful for you @boydm? What do you think could cause 255 return?

I have finally found it!

This is important message for Gentoo and Gentoo-based distribution users.

wayland USE flag causes 255 error for compiled scenic_driver_glfw binary when running in X11 session. I have no Wayland and XWayland sessions to test them properly.

Here is example working dependency configuration:

[ebuild   R    ] media-libs/glew-2.1.0:0/2.1::media-kit  USE="-doc -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild   R    ] media-libs/glfw-3.2.1::media-kit  USE="-examples -wayland" 0 KiB
[ebuild   R    ] virtual/pkgconfig-0-r1::core-kit  ABI_X86="(64) -32 (-x32)" 0 KiB

Here is some description to other people which do not know about USE flag system. Gentoo is source-based Linux distribution. You are able to compile any open source software written for Linux as long as you have met dependencies installed in official or unofficial repository (you can create your own local repository also). If it’s not possible to compile project with support for 2 things then usually such flags have collision which you need resolve on your own. Let’s say collision between support for Qt4 and Qt5. It’s also possible that specific project supports both ways at same time, so it can build Qt4 as well as Qt5 library in one build. Therefore I though that I have only optional Wayland support and in fact it causes me trouble.

3 Likes

So… I’d like to get a concise set of instructions for how to install it on Gentoo, but I’m really unfamiliar with it. I’ll help make the description pretty, but you need to help me understand the steps to make it work.

also, since this is a source based distro, does that mean it is less a set of instructions and more a set of helpful hints?

2 Likes

@boydm In my last response to this topic you can see a list of packages. It’s similar to other distributions except that we are compiling package from source + we have some goods (like USE flags) just because we are compiling sources.

USE flags could be global or per package. They are nice for to unify support for some things. Let’s say that one package have build option --add-bluetooth and second --with-bluetooth. In Gentoo and Gentoo-based source distributions we have one USE flag for example bluetooth to not carry how to pass it to build script. How much USE flag affects configuration and compilation of sources you can find in *.ebuild packages.

We are disabling USE flag if for example we don’t have any bluetooth device or we simply do not need support for it. In result compiled binaries are much smaller and something also faster, because we do not call code which support is optional and we do not need it.

In this case simply we have also 3 packages (with a bit different names than in other distributions) which we need to mention in requirements. We also need to note that compiling media-libs/glfw with wayland support may cause problems in X11 session, so if compiled scenic binary returns 255 error then developer should check if wayland support causes such problem. I’m not sure if it’s intended to fail or it’s a bug which would be fixed.

To compile and install package we are using emerge command, but everyone which at least one time installed Gentoo know how to do it, so no need to worry about it. :smiley:

I’m not good at describing, so please let me know if it’s not enough clear for you. :slight_smile: