Open mani-monaj opened 8 years ago
It seems strange that this call failed but not the others (especially the one at the end line 255) when everything is put back. Normally the check line 191 should verify that stdin is really a tty (so normally supporting the ioctl in question).
When the failure occurs, the invocation is done via a shell or an automated tools (I see travis in the path) that does not provide a 'real' tty for stdin ?
It seems strange that this call failed but not the others (especially the one at the end line 255) when everything is put back. Normally the check line 191 should verify that stdin is really a tty (so normally supporting the ioctl in question).
I guess since the failure happens in the constructor first, it will never get a chance to show itself again given that no stdin
is available to this script.
When the failure occurs, the invocation is done via a shell or an automated tools (I see travis in the path) that does not provide a 'real' tty for stdin ?
It is being called from a meta build tool called catkin which itself wraps CMake: https://catkin-tools.readthedocs.org/en/latest/
For the first question I meant, with the patch that catch the exception in the constructor, does it work with other call to the same function ?
I'll take a look on catkin to see if there is something particuliar
For the first question I meant, with the patch that catch the exception in the constructor, does it work with other call to the same function ?
I see. I don't think so. Is there a way that I can force repo
to fetch/use a local copy of alchemy
? This way I can work on a patch.
I'll take a look on catkin to see if there is something particuliar
I can setup an environment that reproduces this bug with catkin
and give you full remote access. If that sounds good, please email me a public key and I will set that up.
In order to build Parrot ARSDK as part of a larger project with CMake, I wrapped the build steps inside a CMake
custom_target
. The issue is sometimesalchemy
fails due to the following error:The exception happens in the constructor of
JobCtrl
class (os.tcgetpgrp
call)I could not track down the root cause of the issue, however I think the following change should fix the problem: