Pipe timeout oftens in tag 0.0.3

[Traxes]

Hi,

Thanks for the update :-). Unfortunately now the pipe/socket does often produce timeouts.

Appears to happen more often when some load is going through the connection. (Maybe connected to the newly added threading)

tag 0.0.2 is still stable for me.

  File "/Users/Traxes/PycharmProjects/zeno/src/avd/wrapper/BackendGhidra.py", line 137, in do_backward_slice
    if tok.getVarnode():
  File "/usr/local/lib/python3.7/site-packages/ghidra_bridge/bridge.py", line 929, in __call__
    return self._bridge_conn.remote_call(self._bridge_handle, *args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/ghidra_bridge/bridge.py", line 630, in remote_call
    return self.deserialize_from_dict(self.send_cmd(command_dict))
  File "/usr/local/lib/python3.7/site-packages/ghidra_bridge/bridge.py", line 569, in send_cmd
    cmd_id, timeout=self.RESPONSE_TIMEOUT)
  File "/usr/local/lib/python3.7/site-packages/ghidra_bridge/bridge.py", line 387, in get_response
    "Didn't receive response {} before timeout".format(response_id))
Exception: Didn't receive response 0a005460-93f5-46cd-8807-71f08280ebb6 before timeout

Thanks for updating it regulary :-) Helps a lot.

Cheers,
Traxes

[justfoxing]

Ah, that sucks. I'll work on getting out a new version that allows you to set the response timeout ASAP, to see if that will help. I'll let you know once that's up. In the meantime, if you get a chance to answer some of the questions below, that'd be helpful in trying to track down if there's an issue beyond just congestion causing the slow down. * What's your environment like? Are the client and server talking over localhost, or are they on different hosts? * Is Ghidra under any load apart from the server script (e.g., is it running analyses in the background)? * How reliable is the timeout? Does it always happen, or does the script sometimes succeed? Does it happen at the same point in the script or different points? Does your script run okay for a while and then hit the timeout? Mostly trying to identify if this is more likely to be associated with a particular type of command that's slow, or if I'm leading something that causes the server to get progressively slower.

…

On Wed., 29 May 2019, 23:23 Traxes, ***@***.***> wrote: Hi, Thanks for the update :-). Unfortunately now the pipe/socket does often produce timeouts. Appears to happen more often when some load is going through the connection. (Maybe connected to the newly added threading) tag 0.0.2 is still stable for me. File "/Users/Traxes/PycharmProjects/zeno/src/avd/wrapper/BackendGhidra.py", line 137, in do_backward_slice if tok.getVarnode(): File "/usr/local/lib/python3.7/site-packages/ghidra_bridge/bridge.py", line 929, in __call__ return self._bridge_conn.remote_call(self._bridge_handle, *args, **kwargs) File "/usr/local/lib/python3.7/site-packages/ghidra_bridge/bridge.py", line 630, in remote_call return self.deserialize_from_dict(self.send_cmd(command_dict)) File "/usr/local/lib/python3.7/site-packages/ghidra_bridge/bridge.py", line 569, in send_cmd cmd_id, timeout=self.RESPONSE_TIMEOUT) File "/usr/local/lib/python3.7/site-packages/ghidra_bridge/bridge.py", line 387, in get_response "Didn't receive response {} before timeout".format(response_id)) Exception: Didn't receive response 0a005460-93f5-46cd-8807-71f08280ebb6 before timeout Thanks for updating it regulary :-) Helps a lot. Cheers, Traxes — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#12?email_source=notifications&email_token=AENHWIEM34GBPGC4PPE55Y3PXZ7VTA5CNFSM4HQMXYK2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GWPP53Q>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AENHWIFZYJOZA2K33KREJ4TPXZ7VTANCNFSM4HQMXYKQ> .

[justfoxing]

I've just pushed version 0.0.4, which allows you to control the response timeout. I'd suggest trying something like GhidraBridge(namespace=globals(), response_timeout=2) and see if that helps any.

I'd be really keen to hear what length of timeout you finally need to avoid issues (especially if it doesn't stop the issues, or only delays them). And if you get a chance to look at the questions above while you're playing with that, that'd be really helpful.

[justfoxing]

Actually, if you haven't grabbed 0.0.4 already, please try 0.0.5 instead - all the response_timeout features, plus a couple of improvements/bugfixes which might also help.

[justfoxing]

No response, so I'll close this with the note that I've bumped the default response timeout up to 2 seconds.