User input broken on raspbian, Ideas?
See original GitHub issueI have openHTF up and running in a virtual machine running Ubuntu 18.04.2 LTS with Python 3.6.8 so far so good. The examples from the example folder are running without problems.
I like to use the software on a Raspberry Pi 3B running latest raspbian. I tried python 3.5.3 (default on raspbian) and complied installed python 3.6.8 from source, both versions showing the same behavior/error.
Running hello_world_py:
(dhe) pi@openhtfpi:~/playground/openhtf/examples $ python --version
Python 3.6.8
(dhe) pi@openhtfpi:~/playground/openhtf/examples $ python hello_world.py
enter prompt
Enter a DUT ID in order to start the test.
exit prompt
--> testpoint 2 - 86400
Traceback (most recent call last):
File "hello_world.py", line 89, in <module>
test.execute(test_start=user_input.prompt_for_test_start())
File "/home/pi/python-environments/dhe/lib/python3.6/site-packages/openhtf/core/test_descriptor.py", line 349, in execute
outcome=final_state.test_record.outcome.name,
AttributeError: 'NoneType' object has no attribute 'name'
The test doesn’t wait at the user input and throws the error directly. During debugging I added the "testpoint2 in user_input.py:
def wait_for_prompt(self, timeout_s=None):
"""Wait for the user to respond to the current prompt.
Args:
timeout_s: Seconds to wait before raising a PromptUnansweredError.
Returns:
A string response, or the empty string if text_input was False.
Raises:
PromptUnansweredError: Timed out waiting for the user to respond.
"""
with self._cond:
if self._prompt:
if timeout_s is None:
self._cond.wait(3600 * 24 * 365)
else:
print ('testpoint 2 - ' + str(timeout_s) )
self._cond.wait(timeout_s)
print ('testpoint 3 - ' + str(timeout_s) )
if self._response is None:
raise PromptUnansweredError
print ('self._response' + str( self._response ) )
return self._response
So my guess is, that the wait is working but somehow the user_input returns immediately on the Raspberry Pi, therefore the name is not set and the test runs into the exception.
Any ideas what is going wrong here. Must be soemething raspbian specific…
Best, Robert
Issue Analytics
- State:
- Created 4 years ago
- Comments:18
Top GitHub Comments
This sounds plausibly like a 32-bit overflow issue. The Python runtime adds the the timeout to the current time in a time_t variable, which is likely a signed 32-bit number. The
9223372036.0
timeout plus the current unix time winds up negative, so the internal wait finishes immediately.584950000.0
is also just enough more than now to also overflow to negative.I’ll revert the offending commit.
Thanks @justinsg for the additional details.
Thank you it does work now.