XIO: fatal IO error - when starting BEE under Ubuntu 17.04

[I-R]

Hi,

after some struggle, fetching all the libraries together, i still can't run BEE with the python3.5 interpreter. When it gets to start the UI, i get

reimann@Anor:~/src/BEE2.4$ python3 src/BEE2.py [INFO] utils.setup_localisations(): Language: 'de_DE' [WARNING] utils.setup_localisations(): Can't find translation for codes: ['de_DE.ISO8859-1', 'de_DE', 'de.ISO8859-1', 'de']! [WARNING] BEE2_config.load(): Config "../config/packages.cfg" not found! Using defaults... [WARNING] BEE2_config.load(): Config "../config/item_cust_configs.cfg" not found! Using defaults... [WARNING] BEE2_config.load(): Config "../config/games.cfg" not found! Using defaults... [WARNING] BEE2_config.load(): Config "../config/item_configs.cfg" not found! Using defaults... XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 455 requests (455 known processed) with 1 events remaining. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 456 requests (456 known processed) with 1 events remaining.`

I use Cinnamon, tested also software rendering, running with different GPUs (Intel vs. Nvidia) always the same result.

Any Idea?

[homelessturret]

(I belive) This mod only works with Windows 7, 8, and 10.

[TeamSpen210]

You might want to try reinstalling Tkinter, and/or X-server (maybe?).

[I-R]

no, sorry. Other programs user python3/tk do work. I guess, you use some modes when initializing the window, which are not -sort of- compatible?

[John2027]

Simple fix: Stop using Ubuntu and Buy a 30$ copy of windows. And then complain to me that you are poor or your computer is not compatible so you can't buy it. Buy a better pc.

[TeamSpen210]

That's not a solution.

[John2027]

I tried...

[I-R]

I run dual boot on my system, but want to avoid the switching. In my understanding BEE should run nicly on Ubuntu, but it does not and i don`t see the reason.

[Konclan]

Is this still an issue?

[LautaroL20]

Is this still an issue?

Yes it is, according with this: https://github.com/BEEmod/BEE2.4/issues/1653

[Neightro]

I'm experiencing a similar issue on Manjaro Linux. This is what happens after compiling and running the executable:

[I] utils.setup_localisations(): Language: 'en_US'
[I] BEE2_launch.<module>(): Arguments: ['./BEE2']
[I] BEE2_launch.<module>(): Running "bee2", version :
XIO:  fatal IO error 2 (No such file or directory) on X server ":0"
      after 30 requests (30 known processed) with 2 events remaining.
XIO:  fatal IO error 0 (Success) on X server ":0"
      after 56 requests (56 known processed) with 2 events remaining.

From searching online a little bit, it seems like the issue has been caused in other applications by:

• non-native monitor resolutions (https://forum.mxlinux.org/viewtopic.php?f=108&t=56699). I'm running in a multihead setup with one monitor rotated, though unplugging the rotated monitor does not improve results.
• By loading large icons. BEE2.ico doesn't seem especially large, so I doubt that's the issue; replacing it with a smaller icon didn't change anything. I could try disabling my icon theme later, but since I'm not using a desktop environment that would take a little tinkering.

Specs:

• Python 3.9.7
• xorg-server 1.20.13-3
• AMD Radeon

Installed Python libraries: piplist.txt

I don't have any other Linux installations around with Portal 2 installed, but I have a fairly bare-bones Arch Linux VM that I could try installing on later. I'll give that a go if nobody else has any other ideas of what to try.

[ErrorJan]

I have a similar issue under Manjaro Linux. When I run the compiled version or the python one ("src/BEE2_launch.pyw") directly then this happens:

[I] BEE2_launch.<module>(): Arguments: ['BEE2_launch.pyw']
[I] BEE2_launch.<module>(): Running "bee2", version 2.4.41.0.dev+5e07112b 64-bit:
[I] localisation.setup(): Language: 'de_DE'
[W] localisation.setup(): Can't find translation for codes: ['de_DE.ISO8859-1', 'de_DE', 'de.ISO8859-1', 'de']!
X connection to :1 broken (explicit kill or server shutdown).
X connection to :1 broken (explicit kill or server shutdown).

I'm not familiar with Python but I tried debugging it and a very weird thing happened.

I set a break point in the "src/app/tk_tools.py" file at line 408 and when I debugged it, it halted there as it should. Then I let it execute further (awaiting a next breakpoint). I did this as long as there was no new text coming from the terminal. After the second time the program started working (although kinda buggy). You can't drag from the left side to the right side but the program itself seems to be partially working.

When I let the debugger continue again twice then it crashes again and the message

X connection to :1 broken (explicit kill or server shutdown).
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
python: xcb_io.c:269: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

comes up.

I attached a video that I made to showcase it: https://user-images.githubusercontent.com/50844353/151416012-de9027a0-ef0b-423b-a03d-f8345a015f19.mp4

[MrSimbax]

After toying with the debugger for a while and looking through the code, I believe the issue is related to multithreading and/or the daemon subprocess. The fact that the app crashes in seemingly random places but kind of works when setting debugger breakpoints in some also seemingly random places smells like a concurrency issue to me.

One consistent "crashing place" I've found is this line https://github.com/BEEmod/BEE2.4/blob/master/src/bg_daemon.py#L598 This is the first time a Tk widget is created in a subprocess. It crashed every time for me inside the Tkinter lib on self.tk.call(...), so the subprocess is killed instantly without doing anything useful but BEEmod is unaware of that and keeps working without it, at least up until some another weird issue appears which I assume is also related to concurrency.

Unfortunately, I wasn't able to step inside tk.call(...), the subprocess just dies instantly when I do that, with the X connection to :1 broken (explicit kill or server shutdown). log. Surprisingly or perhaps not surprisingly, the main GUI still sometimes work and I could even create and save a palette, there's just no loading screens which I assume are handled in the subprocess.

From what I've read over several random links from Google I get the impression that everyone says that Tkinter is not thread safe and therefore should only be used inside the main thread. It is not the case in BEEmod, because at least the daemon subprocess manages the GUI on its own. Maybe some subthreads also interact with Tkinter. So I think there are three solutions, which might actually fix more than one issue if the lack of thread-safeness of Tkinter really is the root of the problem.

1. TK_ROOT in the app module should be reinitialized in the subprocesses/other threads. This doesn't seem like a simple task because BEEmod uses a lot of global variables and does a lot of initialization in module scope. And I'm not even sure that calling tk.Tk() a second time in a subprocess will help at all or if it will cause even more havoc.
2. Rewrite BEEmod so that all UI operations are in the main thread, and so that other threads and subprocesses do not touch Tkinter at all. As far as I can see, this would be a lot of work but it seems like the cleaner solution.
3. Investigate the code further to find a way to use Tkinter in a thread-safe way from multiple threads/subprocesses.

Keep in mind that I am not a Python expert so I might just be spitting nonsense, but I've decided to share my findings in hopes that they might help figuring out this and perhaps other issues.

[TeamSpen210]

Ooh, that makes sense yes. The subprocess is supposed to be totally independent, it should have re-initialised Tkinter entirely. Perhaps this is a forking issue? Dedent this line, to make multiprocessing spawn a new process instead of forking the existing one.

I'm sorta working on getting rid of the background process, but I basically need to go through all the code and make it non-blocking/async. The process was my solution to ensure the loading screen and logs window remain responsive while the main app is busy doing its thing.

[fourteentrees]

Ooh, that makes sense yes. The subprocess is supposed to be totally independent, it should have re-initialised Tkinter entirely. Perhaps this is a forking issue? Dedent this line, to make multiprocessing spawn a new process instead of forking the existing one.

I'm sorta working on getting rid of the background process, but I basically need to go through all the code and make it non-blocking/async. The process was my solution to ensure the loading screen and logs window remain responsive while the main app is busy doing its thing.

This solution works, but it's buggy as hell. You're better off with a Windows VM running Portal 2 and BEE that way.