No-debug-dissector in UTscapy - stabilize

[gpotter2]

• create a no_debug_dissector shortcut for tests
• stabilize nmap tests

[polybassa]

@gpotter2 This test is showing an issue in automaton.py.

Exception in thread Thread-2614:
Traceback (most recent call last):
  File "C:\Python27-x64\lib\threading.py", line 801, in __bootstrap_inner
    self.run()
  File "C:\Python27-x64\lib\threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "scapy\ansmachine.py", line 202, in __call__
    self.sniff()
  File "scapy\ansmachine.py", line 208, in sniff
    sniff(**self.optsniff)
  File "scapy\sendrecv.py", line 1310, in sniff
    sniffer._run(*args, **kwargs)
  File "scapy\sendrecv.py", line 1257, in _run
    session.on_packet_received(p)
  File "scapy\sessions.py", line 106, in on_packet_received
    result = self.prn(pkt)
  File "scapy\ansmachine.py", line 181, in reply
    self.send_reply(reply)
  File "scapy\contrib\automotive\ecu.py", line 712, in send_reply
    self._main_socket.send(p)
  File "test\testsocket.py", line 69, in send
    super(TestSocket, r).send(sx)  # type: ignore
  File "scapy\automaton.py", line 183, in send
    os.write(self.__wr, b"X")
OSError: [Errno 9] Bad file descriptor

The same issue happened on the current master build. I've never observed this issue on Linux/BSD based CI-machines. Do you have an idea how to debug such a case? To me, it looks like the OS is doing something weird, for example closing the files used in ObjectPipe.

The ObjectPipe used by the TestSocket was clearly open in the beginning of this test case, which means, the OS decided to close this file during the execution of the test case.

[gpotter2]

It looks like this is trying to write on a closed object. I would suspect that's due to the fact that you're using threads: do you think it would be possible that the descriptors are closed, while having a thread still trying to access them?

[polybassa]

I checked the code, but from the given information, this Exception happened in my "background" thread which is running an answering machine. The socket of this answering machine is not closed by any operation in my code. The GC will close it, after the test. This brings me to the assumption that the OS was closing it. This TestSocket is not shared between multiple threads. Only the AnsweringMachine Thread is using it. I don't see a way, how threading could cause this error.