You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is actually more like a follow up of #48 : Currently we can configure the timeout value using either response_timeout parameter for GhidraBridge, or timeout_override parameter for remote_eval.
However, when I set both values to -1 on client side (which should disable any timeout threshold) , a BridgeTimeoutException exception was still raised when I try to run a pretty large function using remote_eval. After some simple debugging, I found that the exception was actually raised from ghidra_bridge_server.py. More specific, it's the timeout value setup when constructing a jfx_bridge.BridgeServer object (line). And apparently this timeout value is fixed when using ghidra_bridge_server.py with analyzeHeadless.
I'm wondering if we can just set the timeout value here to -1 and let the client decide which timeout to use (using the existing response_time and timeout_override)? Or add a command line flag for ghidra_bridge_server.py to configure the timeout?
The text was updated successfully, but these errors were encountered:
mshockwave
changed the title
Timeout values are not configurable for both ghidra_bridge_server.py and ghidra_bridge_server_background.py
Timeout value is not configurable in ghidra_bridge_server.pyJan 28, 2021
Sorry, got distracted and didn't ever comment on this. This is particularly risky, because the server is pushing callbacks to the client fairly regularly in interactive mode (e.g., every time you scroll), from the GUI thread - if the client disconnects and there's no timeout, the whole Ghidra environment would lock up.
Ghidra's GUI script environment doesn't provide a great way to take arguments.
Taking the values from the connected client is probably the best idea, and the response_timeout is contained in the BridgeConn associated 1:1 with each client, so multiple clients shouldn't affect each other. I just need to find some time to write the code and tests.
As a quick hacky fix for this:
defset_remote_bridge_timeout(connected_bridge, new_timeout):
""" Gross hack to set the response timeout on the remote bridge end. """# get the remote bridge conn, by getting the frame inside local_eval, then the frame that called that (f_back), then the locals of the caller, which include the BridgeConn as selfbc=connected_bridge.remote_eval("__import__('inspect').currentframe().f_back.f_locals['self']")
bc.response_timeout=new_timeoutb.set_remote_bridge_timeout(b, -1)
Hi,
This is actually more like a follow up of #48 : Currently we can configure the timeout value using either
response_timeout
parameter forGhidraBridge
, ortimeout_override
parameter forremote_eval
.However, when I set both values to -1 on client side (which should disable any timeout threshold) , a
BridgeTimeoutException
exception was still raised when I try to run a pretty large function usingremote_eval
. After some simple debugging, I found that the exception was actually raised fromghidra_bridge_server.py
. More specific, it's the timeout value setup when constructing ajfx_bridge.BridgeServer
object (line). And apparently this timeout value is fixed when usingghidra_bridge_server.py
withanalyzeHeadless
.I'm wondering if we can just set the timeout value here to -1 and let the client decide which timeout to use (using the existing
response_time
andtimeout_override
)? Or add a command line flag forghidra_bridge_server.py
to configure the timeout?The text was updated successfully, but these errors were encountered: