IO errno 5.

[nukdokplex]

Describe the bug
IO errno 5.

To Reproduce
I don't know how to reproduce this. It's random. For example last error was in a moment when i quit a game.

Expected behavior
No IO error OR not static screen. Maybe this IO error we can just ignore and don't stop queue?

Screenshots / photos of the Turing screen
So this is error in logs:

And here is ls /dev/tty*

Environment:

• 1b444aa
• Manjaro latest
• Python 3.11
• MSI Z170A GAMING M5, Intel Core i7 6700K, AMD Radeon RX6700XT

Additional context
Increased update time to minimum 2 secs in theme. systemctl restart turing restarts screen successfully and it continues working.

[nneul]

Seeing this as well. I'd be fine if it would actually crash - but the way it's currently behaving, it just hangs and doesn't terminate with the exception. If it exited the service could at least restart.

[nukdokplex]

@nneul but exception doesn't repeating. I think thread is actually stopped and doesn't throw this exception again. So there is two possible explanations:

1. Thread is actually stopped.
2. Thread writes serial without any errors, but screen doesn't update.

I could test this if I could somehow turn off screen restart during script initialization. If the first statement is true, then the screen should continue to update, if not, then the second statement is true. Please check if my logic is correct?

[nneul]

Probably easy enough to add a bit of debugging to write out a plain text debug message every N passes through the thread that is doing the serial writes. I think your logic makes sense.

[nneul]

It actually looks like it's being fired off as a repeating invoked function, and not a looped thread. I've added some logging to my instance, and will see if there is anything useful in output.

[nukdokplex]

Ok, so, i think that i can reproduce this strange bug. I quit a videogame (Prey 2017 via lutris proton if necessary) and screen was stuck instantly. I really don't know htf this s is connected, but... it is! And i don't know is it specific problem of proton, of prey or lutris. If anyone have some guesses i will listen very carefuly. So... WTF???

[nneul]

Not familiar with the game - but - does it use a headset? Maybe there is some sort of USB bus reset or other operation that is making the turing 'stumble'?

No video games in my case.

Does it happen every time you exit the game?

[nukdokplex]

@nneul yes, every time. And i don't use usb headset - it's jack3.5.

[nneul]

Meaning of that output - I wrapped each invocation of the callback function in the queue with prints of < and > respectively. The thread is either terminating or hanging in the middle of invocation of the callback function.

[nneul]

Could potentially be handled by adding a try around the queue callback function, and then if it traps an IO error, set a global to get it to exit the entire app or reestablish the serial connection.

[nukdokplex]

@nneul i'm waiting for that commit

[nneul]

Not sure what you mean - I don't have any fix - I'm just another user of this -- not the developer. Above was just a possible suggestion on maybe how to address it - not something I'm directly working on.

[mathoudebine]

@nukdokplex and @nneul I tried to make a fix for the issue you are encountering: on I/O error the program will close and reopen the COM port before a retry.
Can you test the branch fix/269-io-errno-5 and tell me if the fix works for you? I cannot reproduce the issue on my side, so I can't tell if it would work or not. Thanks!

[nneul]

I've installed it, will see if it looks, but it's relatively infrequent on my system. If @nukdokplex can easily reproduce that's going to be best test case.