labath added a comment.

In D110878#3034748 <https://reviews.llvm.org/D110878#3034748>, @mgorny wrote:

> @labath, this is the part where I ask for help ;-).
>
>   An exception happened when receiving the response from the gdb server. 
> Closing the client...
>   Traceback (most recent call last):
>     File 
> "/home/mgorny/git/llvm-project/lldb/test/API/functionalities/gdb_remote_client/gdbclientutils.py",
>  line 405, in _run
>       data = seven.bitcast_to_string(self._client.recv(4096))
>     File 
> "/home/mgorny/git/llvm-project/lldb/test/API/functionalities/gdb_remote_client/gdbclientutils.py",
>  line 538, in recv
>       return self.read(size)
>   OSError: [Errno 5] Input/output error
>   PASS: LLDB (/home/mgorny/git/llvm-project/build/bin/clang-x86_64) :: 
> test_process_connect_sync_dwarf (TestPty.TestPty)
>
> I think it's getting in the 'controlling terminal' magic and getting EIO when 
> lldb finishes or sth like that. Any suggestion how to avoid this exception?

Catch it and turn it into EOF? (btw, I've found this link 
<https://unix.stackexchange.com/questions/538198/why-blocking-read-on-a-pty-returns-when-process-on-the-other-end-dies>
 to be pretty good at explaining the behavior across different OSs.)



================
Comment at: 
lldb/test/API/functionalities/gdb_remote_client/gdbclientutils.py:530-535
+    def accept(self):
+        return self, ''
+
+    def close(self):
+        # the socket is reused, so don't close it yet
+        pass
----------------
I think it would be cleaner if we had like a single new interface, which 
describes what to we expect of the connection, and then a socket- and pty-based 
implementation of that interface.


================
Comment at: 
lldb/test/API/functionalities/gdb_remote_client/gdbclientutils.py:560-564
+    def get_connect_address(self):
+        libc = ctypes.CDLL(None)
+        libc.ptsname.argtypes = (ctypes.c_int,)
+        libc.ptsname.restype = ctypes.c_char_p
+        return libc.ptsname(self._master).decode()
----------------
I'm wondering if we should have an overload of SBTarget::ConnectRemote that 
accepts a file descriptor (or SBFile, SBCommunication, ...).

This would make the socket case easier as well, and it seems like it could be 
generally useful.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110878/new/

https://reviews.llvm.org/D110878

_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to