If this should be a Gazebo issue feel free to reassign. Gazebo, gzclient, pins the CPU. We don't see this when using ssh -X, e.g., from a Mac with XQuartz, nor Windows with MobaXterm. 5.7.15-200.fc32.x86_64, gazebo-11.1.0-2.fc32.x86_64 top - 09:31:06 up 33 days, 17:28, 4 users, load average: 2.15, 0.74, 0.44 Tasks: 806 total, 3 running, 803 sleeping, 0 stopped, 0 zombie %Cpu(s): 17.6 us, 0.4 sy, 0.0 ni, 81.7 id, 0.0 wa, 0.1 hi, 0.1 si, 0.0 st MiB Mem : 128537.7 total, 58096.7 free, 11477.8 used, 58963.1 buff/cache MiB Swap: 15260.0 total, 15178.2 free, 81.8 used. 115554.7 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 523200 me 20 0 14.0g 343892 146472 R 826.2 0.3 2:40.46 gzclient 523199 me 20 0 12.0g 200884 117124 S 7.6 0.2 0:03.21 gzserver 521547 me 20 0 202364 94772 25548 S 4.3 0.1 0:03.45 x2goagent We see this in /var/log/messages: Sep 22 09:30:11 us dbus-broker-launch[522115]: Activation request for 'org.a11y.atspi.Registry' failed. And from launching with verbose option: [Wrn] [GuiIface.cc:119] X server does not support XInput 2 [Wrn] [GuiIface.cc:119] QXcbConnection: XCB error: 1 (BadRequest), sequence: 168, resource id: 158, major code: 130 (Unknown), minor code: 47
I would highly recommend sending this to the x2go users mailing list. They are pretty helpful there and I have no time or insight. I'm re-assigning to gazebo just to bring them in and see if they have any insight. If you connect with strace to gzclient, what is it doing?
(In reply to Orion Poplawski from comment #1) > I would highly recommend sending this to the x2go users mailing list. They > are pretty helpful there and I have no time or insight. I did to the dev list, it's been a few days, haven't head from Ulrich. He did help me troubleshoot the previous bug where Gazebo just didn't launch https://bugzilla.redhat.com/show_bug.cgi?id=1871291 > I'm re-assigning to gazebo just to bring them in and see if they have any > insight. Great, perhaps Rich M. will have an idea > If you connect with strace to gzclient, what is it doing? A whole lotta this: poll([{fd=37, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=37, revents=POLLOUT}]) writev(37, [{iov_base="\21\0\2\0\257\0\0\0", iov_len=8}], 1) = 8 futex(0x7fffb51898c8, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 futex(0x55c3bb006008, FUTEX_WAKE_PRIVATE, 1) = 0 poll([{fd=37, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=37, revents=POLLOUT}]) writev(37, [{iov_base="\21\0\2\0\207\0\0\0\21\0\2\0\214\0\0\0\21\0\2\0\230\0\0\0\21\0\2\0\231\0\0\0", iov_len=32}], 1) = 32 futex(0x7fffb51898e8, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 futex(0x55c3bb006008, FUTEX_WAKE_PRIVATE, 1) = 0 poll([{fd=37, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=37, revents=POLLOUT}]) writev(37, [{iov_base="\21\0\2\0\260\0\0\0", iov_len=8}], 1) = 8 futex(0x7fffb51898c8, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 futex(0x55c3bb006008, FUTEX_WAKE_PRIVATE, 1) = 0 poll([{fd=37, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=37, revents=POLLOUT}]) writev(37, [{iov_base="\21\0\2\0\207\0\0\0\21\0\2\0\230\0\0\0\21\0\2\0\231\0\0\0\21\0\2\0\232\0\0\0", iov_len=32}], 1) = 32
There's a reply on the x2go-dev list at https://www.mail-archive.com/x2go-dev@lists.x2go.org/msg06259.html > [Wrn] [GuiIface.cc:119] X server does not support XInput 2 This one is the problem. "What the Gazebo Client devs could.do is: fall back to Xinput1 if Xinput2 is unavailable." > [Wrn] [GuiIface.cc:119] QXcbConnection: XCB error: 1 (BadRequest), > sequence: 168, resource id: 158, major code: 130 (Unknown), minor code: 47 ... and the XClient gzclient dies...
This bug was closed but where should I report this? Seems to have gotten worse: gazebo-11.1.0-2.fc33.x86_64, 5.9.16-200.fc33.x86_64 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 167977 myuser 20 0 19.6g 325912 148004 S 882.6 0.2 5:33.38 gzclient And from strace, wouldn't all of the "Resource temporarily unavailable" be troublesome? futex(0x557771fbecec, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 futex(0x557771fbec98, FUTEX_WAKE_PRIVATE, 1) = 0 poll([{fd=32, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=32, revents=POLLOUT}]) writev(32, [{iov_base="\201\3\n\0\4\0\200\2\3\0`\2\300\3@\2\0\0\0\0\300\3@\2\0\0\0\0\30\2\0\2"..., iov_len=40}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 40 recvmsg(32, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(32, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=37, events=POLLIN}, {fd=38, events=POLLIN}, {fd=45, events=POLLIN}], 3, 0) = 0 (Timeout) write(37, "\1\0\0\0\0\0\0\0", 8) = 8 write(37, "\1\0\0\0\0\0\0\0", 8) = 8 poll([{fd=37, events=POLLIN}, {fd=38, events=POLLIN}, {fd=45, events=POLLIN}], 3, 0) = 1 ([{fd=37, revents=POLLIN}]) read(37, "\2\0\0\0\0\0\0\0", 16) = 8 futex(0x557771fbecec, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 futex(0x557771fbec98, FUTEX_WAKE_PRIVATE, 1) = 0 poll([{fd=32, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=32, revents=POLLOUT}]) writev(32, [{iov_base="\16\3\2\0\4\0\200\2", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8 poll([{fd=32, events=POLLIN}], 1, -1) = 1 ([{fd=32, revents=POLLIN}]) recvmsg(32, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\30=\5\0\0\0\0\236\0\0\0\0\0\0\0\254\3@\2\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 futex(0x557771fbecec, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 futex(0x557771fbec98, FUTEX_WAKE_PRIVATE, 1) = 0 poll([{fd=32, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=32, revents=POLLOUT}]) writev(32, [{iov_base="\201\3\n\0\4\0\200\2\3\0`\2\300\3@\2\0\0\0\0\300\3@\2\0\0\0\0\30\2\0\2"..., iov_len=40}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 40 recvmsg(32, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(32, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=37, events=POLLIN}, {fd=38, events=POLLIN}, {fd=45, events=POLLIN}], 3, 0) = 0 (Timeout) write(37, "\1\0\0\0\0\0\0\0", 8) = 8 write(37, "\1\0\0\0\0\0\0\0", 8) = 8 poll([{fd=37, events=POLLIN}, {fd=38, events=POLLIN}, {fd=45, events=POLLIN}], 3, 0) = 1 ([{fd=37, revents=POLLIN}]) read(37, "\2\0\0\0\0\0\0\0", 16) = 8 write(37, "\1\0\0\0\0\0\0\0", 8) = 8 futex(0x7f82a1f3f958, FUTEX_WAKE_PRIVATE, 2147483647) = 1
> "What the Gazebo Client devs could.do is: fall back to Xinput1 if Xinput2 is unavailable." This sounds like a change to Gazebo itself, and isn't a problem in packaging. If there was a fix, it would land there: https://github.com/osrf/gazebo/issues/2846 I don't think there is any reason to track it here, specifically because there isn't anything to be done here to fix the bug, and there isn't anything to do when it is fixed upstream. This is even more true because Gazebo 11 hasn't been officially packaged for Fedora.