py65
py65 copied to clipboard
error with stdin - termios.error (with patch)
hi,
we have some problems with the termios module. sometimes we get a error code 25 as you can see below. Py65 Monitor PC AC XR YR SP NV-BDIZC` 65C02: 0000 00 00 00 ff 00110000 .Wrote +2955 bytes from $e800 to $f38a PC AC XR YR SP NV-BDIZC 65C02: 0000 00 00 00 ff 00110000 .Error: <class 'termios.error'>, (25, 'Inappropriate ioctl for device'): file: /usr/lib/python3.6/site-packages/py65/utils/console.py line: 54 ...
i've created a patch that "works for me". at least i just catch the termios.error in console.getch_noblock() and answer "nothing". within monitor and _install_mpu_observers.getc i also return nothing if there where no char read. maybe thats not a good solution, but sometimes termios behaves very odd.
problem is reproducable: native linux and cygwin, python3.6
cheers
Contents of termios.patch.gz
from above:
:100644 100644 b63db62 0000000 M py65/monitor.py
:100644 100644 eb15df0 0000000 M py65/utils/console.py
diff --git a/py65/monitor.py b/py65/monitor.py
index b63db62..096f974 100644
--- a/py65/monitor.py
+++ b/py65/monitor.py
@@ -235,9 +235,8 @@ class Monitor(cmd.Cmd):
char = console.getch_noblock(self.stdin)
if char:
byte = ord(char)
- else:
- byte = 0
- return byte
+ return byte
+ return
m = ObservableMemory(subject=self.memory, addrWidth=self.addrWidth)
m.subscribe_to_write([self.putc_addr], putc)
diff --git a/py65/utils/console.py b/py65/utils/console.py
index eb15df0..4984a5a 100644
--- a/py65/utils/console.py
+++ b/py65/utils/console.py
@@ -50,8 +50,10 @@ else:
"""
fd = stdin.fileno()
-
- oldterm = termios.tcgetattr(fd)
+ try:
+ oldterm = termios.tcgetattr(fd)
+ except termios.error:
+ return
newattr = oldterm[:]
newattr[3] = newattr[3] & ~termios.ICANON & ~termios.ECHO
termios.tcsetattr(fd, termios.TCSANOW, newattr)
problem is reproducable: native linux and cygwin, python3.6
Can you please provide instructions for how to reproduce it? I have not been able to observe this error.
hi,
cannot provide a standalone test, but if you're going to checkout our steckschwein repo https://bitbucket.org/steckschwein/steckschwein-code and then build with
make (cd steckos/kernel/test;make) => will produce the error
if a standalone test is desired, maybe i'll try to setup one. imo it has something to do withe in/out "hook" and if you run a program which uses them.
I have committed a version of your patch in 7ed4d95885f91b70c5814ec308d5d2eb78d13f23. Please let me know if this fixes the problems that you were having running the Steckschwein tests. We can continue to iterate on it if not. Thanks for the report!
About my changes to your patch:
I did not commit the patch directly because of the change in return types. The getc()
function in monitor.py
originally returned 0
but you changed it to None
. This is will likely cause an error later because the return value is passed to the 6502 emulation code (it will be stored in a memory or a register). Similarly, in the getch_noblock()
function in utils.py
, the function was documented to return an empty string but you changed it to return None
for the case of the termios
error. It would still return an empty string for the normal case. I made it return an empty string in both cases.
hi, and many thx for the fix. sorry, just testet more complex things and going on with more tests @Steckschwein. the error does not appear anymore, but the (asm) program stops and i get back to the monitor at exactly that point where the error would occur without your fix. on error the monitor.py does not distinct the return value from console.py. so on error the monitor.py will return 0 if there was no char answered. this is causing the monitor to stop execution, but this is not what i want. :/ yes, i know my patch has the sideeffect of a different return type, but currently it "works for me", cuz execution continues.
Could you please give me some specific steps that I can do to reproduce the new error? I don't understand what is occurring. I am reluctant to change the return types to be inconsistent. It sounds like maybe it just happened to work accidentally or maybe there are multiple bugs involved. I'll try to fix it but I'd like to understand it before we try just changing things.
Reopening. The issue was accidentally closed by GitHub when I committed cd673d50d1acc3cb3f5d169a7e807fdf812bf7c8 to revert 7ed4d95885f91b70c5814ec308d5d2eb78d13f23.
I'll second the request for specific steps to reproduce this bug, as I am currently playing with that section of code myself.
I've been able to recreate this issue and determine the problem. It's caused when the "stdin" being used by the monitor is not a pty (eg. when it's being redirected from a file or pipe). It can also be caused when running the monitor "inside" of another program, such as an IDE, rather than directly from a shell. mlauke's thought of catching the error and ignoring it is reasonable under the circumstances that cause it, and I will add that to the routines I am working on in utils.console.