You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If being run in a headless environment, e.g. through ssh or with an application that's being unit tested on a CI server, libuiohook causes a segfault during library load:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5ada378 in XkbGetUpdatedMap () from /usr/lib/x86_64-linux-gnu/libX11.so.6
(gdb) bt
#0 0x00007ffff5ada378 in XkbGetUpdatedMap () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#1 0x00007ffff5ada4a5 in XkbGetMap () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#2 0x00007ffff5a3e106 in load_input_helper (disp=0x0) at src/x11/input_helper.c:1801
#3 0x00007ffff5a3da2b in on_library_load () at src/x11/system_properties.c:475
#4 0x00007ffff7fe0b8a in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffe428, env=env@entry=0x7fffffffe438) at dl-init.c:72
#5 0x00007ffff7fe0c91 in call_init (env=0x7fffffffe438, argv=0x7fffffffe428, argc=1, l=<optimized out>) at dl-init.c:30
#6 _dl_init (main_map=0x7ffff7ffe190, argc=1, argv=0x7fffffffe428, env=0x7fffffffe438) at dl-init.c:119
#7 0x00007ffff7fd013a in _dl_start_user () at /lib64/ld-linux-x86-64.so.2
If this registration could be delayed until hook_run or a new setup API is called, then the application could choose to not start hook and avoid the call. As it is now, the application has to avoid linking hook, and instead load the library from code once it's verified that there's a normal display present.
The text was updated successfully, but these errors were encountered:
There is no way this will work with a headless environment. If it doesn't crash onload, it will crash in just about everywhere else. Dynamically loading the library is probably the best option so that it doesn't require a bunch of X11 libraries and runtime if the UI is not present. Let me know if you have a different idea.
I was thinking that on library load libuiohook could not touch anything that required display, and all that could be done in hook_run or something like hook_init. Then even though it would still explode if those API were called in a headless environment, the application could choose when to call those.
For example an application that links against libuiohook and that is made of class A and B could unit test class A without having to instantiate class B, and all calls to libuiohook could be held in class B.
Now, even if all hook API are in a single class that isn't instantiated, the unit test will still fail if libuiohook is linked directly.
Loading dynamically works around this, bit I think being able to link normally would lead to simpler application code and be less error prone.
If being run in a headless environment, e.g. through ssh or with an application that's being unit tested on a CI server, libuiohook causes a segfault during library load:
If this registration could be delayed until
hook_run
or a new setup API is called, then the application could choose to not start hook and avoid the call. As it is now, the application has to avoid linking hook, and instead load the library from code once it's verified that there's a normal display present.The text was updated successfully, but these errors were encountered: