Rack: X Error: BadAtom (invalid Atom parameter)

[mmilata]

OS (if applicable): Fedora 26, x86_64
Version (or "dev" if compiling from source): 0.5.0

Program starts but after a few moments crashes with:

X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  20 (X_GetProperty)
  Atom id in failed request:  0x0
  Serial number of failed request:  10206
  Current serial number in output stream:  10206
terminate called without an active exception
./Rack.sh: line 2: 17252 Aborted                 (core dumped) LD_LIBRARY_PATH=. ./Rack

Stacktrace from logs:

Dec 02 17:36:05 fe /usr/libexec/gdm-x-session[3769]: user error (Error in function getWindowAttributes)
Dec 02 17:36:05 fe systemd-coredump[18051]: Process 18037 (Rack) of user 1000 dumped core.
                                            Stack trace of thread 18037:
                                            #0  0x00007fbc3c61a9fb raise (libc.so.6)
                                            #1  0x00007fbc3c61c800 abort (libc.so.6)
                                            #2  0x00007fbc3cf78025 _ZN9__gnu_cxx27__verbose_terminate_handlerEv (libstdc++.so.6)
                                            #3  0x00007fbc3cf75c16 n/a (libstdc++.so.6)
                                            #4  0x00007fbc3cf75c61 _ZSt9terminatev (libstdc++.so.6)
                                            #5  0x00000000004362d7 _ZNSt6threadD2Ev (Rack)
                                            #6  0x00007fbc3c61efc8 __run_exit_handlers (libc.so.6)
                                            #7  0x00007fbc3c61f01a exit (libc.so.6)
                                            #8  0x00007fbc3c0b8888 _XDefaultError (libX11.so.6)
                                            #9  0x00007fbc3c0b89ba _XError (libX11.so.6)
                                            #10 0x00007fbc3c0b58eb handle_error (libX11.so.6)
                                            #11 0x00007fbc3c0b6a94 _XReply (libX11.so.6)
                                            #12 0x00007fbc3c09c575 XGetWindowProperty (libX11.so.6)
                                            #13 0x00007fbc3e08a08f _glfwGetWindowPropertyX11 (/home/b42/dl/Rack/libglfw.so.3)
                                            #14 0x00007fbc3e08b5c3 _glfwPlatformWindowMaximized (/home/b42/dl/Rack/libglfw.so.3)
                                            #15 0x00007fbc3e08268a glfwGetWindowAttrib (/home/b42/dl/Rack/libglfw.so.3)
                                            #16 0x0000000000448fb6 _ZN4rack14guiIsMaximizedEv (Rack)
                                            #17 0x000000000043679a settingsToJson (Rack)
                                            #18 0x0000000000488ef5 _ZN4rack10RackWidget4stepEv (Rack)
                                            #19 0x000000000047793d _ZN4rack6Widget4stepEv (Rack)
                                            #20 0x000000000047793d _ZN4rack6Widget4stepEv (Rack)
                                            #21 0x000000000047793d _ZN4rack6Widget4stepEv (Rack)
                                            #22 0x000000000047793d _ZN4rack6Widget4stepEv (Rack)
                                            #23 0x000000000047a043 _ZN4rack9RackScene4stepEv (Rack)
                                            #24 0x000000000044abfd _ZN4rack6guiRunEv (Rack)
                                            #25 0x0000000000433405 main (Rack)
                                            #26 0x00007fbc3c60488a __libc_start_main (libc.so.6)
                                            #27 0x0000000000433b69 _start (Rack)

                                            Stack trace of thread 18040:
                                            #0  0x00007fbc3f2b392d __nanosleep (libpthread.so.0)
                                            #1  0x00000000004350ff _ZNSt11this_thread9sleep_forIdSt5ratioILl1ELl1EEEEvRKNSt6chrono8durationIT_T0_EE (Rack)
                                            #2  0x00007fbc3cfa23c0 n/a (libstdc++.so.6)
                                            #3  0x00007fbc3f2a936d start_thread (libpthread.so.0)
                                            #4  0x00007fbc3c6f4e1f __clone (libc.so.6)

[mmilata]

@sorki told me it's because of XMonad, workaround here: https://github.com/sorki/Rack/tree/enowindowinfo

[AndrewBelt]

If you have time, you might want to reproduce this with a trivial GLFW program and see if calling the glfwGetWindowAttrib() function crashes it.

[mmilata]

@AndrewBelt Tried with following but it's probably too trivial:/

#include <GLFW/glfw3.h>
int main(void)
{
    GLFWwindow* window = glfwCreateWindow(640, 480, "My Title", NULL, NULL);
    return glfwGetWindowAttrib(window, 0);
}

[AndrewBelt]

Does it crash?

[mmilata]

Yeah but not in glfwGetWindowAttrib because glfwCreateWindow returns NULL:

a.out: /builddir/build/BUILD/glfw-3.2.1/src/window.c:677: glfwGetWindowAttrib: Assertion `window != NULL' failed.
zsh: abort (core dumped)  ./a.out

Maybe some initialization is needed?

[AndrewBelt]

glfwInit()

[mmilata]

Doesn't crash, returns 0:

#include <GLFW/glfw3.h>
int main(void)
{
    glfwInit();
    GLFWwindow* window = glfwCreateWindow(640, 480, "My Title", NULL, NULL);
    return glfwGetWindowAttrib(window, 0);
}

[madjestic]

The fork seems to work for me. I run XMonad on gentoo and the original version crashed about 4 times in 1 minute. It ran for some time, but as soon as I, it seems, switched windows a few times - it would crash with the same error, as reported by the topic starter.
After compiling the suggested fork, the issue seems to have gone away.

Cheers!

[knownothingbozo]

I had a similar problem running
arch
kernel vervion : 4.15.6-1-ARCH
dwm : 6.1
I had to comment this bit out of "/Rack/src/settings.cpp" ln. 23-33
I assume the issue stems from the tiling window manager clashing with these instructions.

if (!windowIsMaximized()) {
        // windowSize
        Vec windowSize = windowGetWindowSize();
        json_t *windowSizeJ = json_pack("[f, f]", windowSize.x, windowSize.y);
        json_object_set_new(rootJ, "windowSize", windowSizeJ);

        // windowPos
        Vec windowPos = windowGetWindowPos();
        json_t *windowPosJ = json_pack("[f, f]", windowPos.x, windowPos.y);
        json_object_set_new(rootJ, "windowPos", windowPosJ);
}

[GeertJohan]

This is still an issue with xmonad today (ubuntu bionic, xmonad 0.13).

I've been using xmonad for over 4 years and never had an application crashing because of it, so I suspect this is something that can/should be fixed in vcvrack.

[AndrewBelt]

I can't replicate this issue myself, so the issue won't budge until someone researches a fix on their own. @mmilata has stated that it crashes on the call to glfwGetWindowAttrib(), so the scope is very narrow and this should be easy for someone that can replicate the issue, perhaps with an isolated "Hello world" GLFW app.

[sm00th]

It is reproducible with bare-bones GLFW app, though it is only reproducible with GLFW_MAXIMIZED, thats why glfwGetWindowAttrib(window, 0) didn't give an error. It is an issue in glfw, it seems. With xmonad (or dwm in my case) detectEWMH() doesn't go past _NET_SUPPORTING_WM_CHECK if and never populates _glfw.x11.NET_WM_STATE etc.

The less invasive workaround for this is to use wmname.

[afcady]

It still crashes in the same way for me after I set a name with wmname. I'm using xmonad. It happens immediately and reliably upon startup. The trace looks like this:

#9  0x00007ffff744b23d in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6                                              
#10 0x00007ffff7448167 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#11 0x00007ffff744923d in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#12 0x00007ffff742f2de in XGetWindowProperty () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#13 0x000000000059b9ca in _glfwGetWindowPropertyX11 ()
#14 0x000000000059d55c in _glfwPlatformWindowMaximized ()
#15 0x000000000053eaaa in rack::windowIsMaximized() ()
#16 0x0000000000521b70 in rack::settingsSave(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)

[Teteros]

@afcady the workaround mentioned in this comment worked for me, but you need to recompile Rack yourself.

$ patch -Nsp1 badatom-workaround.diff

--- a/src/settings.cpp
+++ b/src/settings.cpp
@@ -20,6 +20,7 @@ static json_t *settingsToJson() {
    json_t *tokenJ = json_string(gToken.c_str());
    json_object_set_new(rootJ, "token", tokenJ);

+    /*
    if (!windowIsMaximized()) {
        // windowSize
        Vec windowSize = windowGetWindowSize();
@@ -31,6 +32,7 @@ static json_t *settingsToJson() {
        json_t *windowPosJ = json_pack("[f, f]", windowPos.x, windowPos.y);
        json_object_set_new(rootJ, "windowPos", windowPosJ);
    }
+    */

    // opacity
    float opacity = gToolbar->wireOpacitySlider->value;

[afcady]

I got it working like so:

diff --git a/src/window.cpp b/src/window.cpp
index 0245f57..4563b44 100644
--- a/src/window.cpp
+++ b/src/window.cpp
@@ -8,6 +8,7 @@
 #include <map>
 #include <queue>
 #include <thread>
+#include <cstdlib>

 #include "osdialog.h"

@@ -559,6 +560,8 @@ void windowSetWindowPos(Vec pos) {
 }

 bool windowIsMaximized() {
+  if (getenv("RACK_XMONAD_HACK"))
+    return true;
    return glfwGetWindowAttrib(gWindow, GLFW_MAXIMIZED);
 }

And then RACK_XMONAD_HACK=y ./Rack brings up the window, while it still segfaults when the variable is unset.

[afcady]

I created PR #1180 with my changes.

[jpotier]

I just hit this again :(

[jpotier]

Also, @afcady 's PR was just closed without merge. So this issue is still very much here.

[jpotier]

Well I used the patch mentioned by @Teteros and it seems to run.

[afcady]

You don't even need to patch VCVRack itself, you just need to upgrade the GLFW dependency. It's a GLFW bug. But yeah it'd sure be nice to release a fixed binary.

[jpotier]

you just need to upgrade the GLFW dependency

I see. Well, maybe in the future it's going to fix itself. My distro's unstable distribution does not (yet) have a recent enough GLFW apparently.

[afcady]

No, it won't ever fix itself. The way that the Rack build works, if you build it according to standard procedure, it bundles its own dependencies and builds a statically linked binary. The distribution's version isn't used.

The problem is already fixed in the Rack 1.0 branch, because the bundled dependencies were updated. But the 0.6 branch is never to be updated, apparently.

[jpotier]

if you build it according to standard procedure, it bundles its own dependencies and builds a statically linked binary.

My distro's package picks a more recent commit of glfw at the moment for v0.6. It is apparently old enough that the fix for the current issue wasn't included.

But the 0.6 branch is never to be updated, apparently.

That's too bad, maybe (human) resources are lacking? It doesn't seem to be super hard to update a submodule. Maybe there are other changes that cause problems.

[afcady]

@jpotier you can see the discussion at #1181

[jpotier]

@afcady yeah, I made a patched build for it (https://framagit.org/mpo/overlays-personal/blob/master/pkgs/vcv-rack/default.nix#L23). Working fine, some random crashes when removing random modules, but all in all I'm having lots of fun with VCV Rack.

Thanks @AndrewBelt !