proc/gdbserver: ignore spurious stop packet from debugserver #3021
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When we send an interrupt request to debugserver we, sometimes, get one extra spurious stop packet back. This stop packet gets interpreted as a response to a qThreadStopInfo request we make causing the protocol to become desynchronized for a while, until eventually some kind of error appears. Here's an example of this problem, distilled from issue go-delve#3013: 1 <- $vCont;c#a8 2 <- interrupt 3 -> $T05thread:12efb47;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,... 4 <- $qThreadStopInfo12efb8e#28 5 -> $T05thread:12efb47;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,... 6 <- $qThreadStopInfo12efb8f#29 7 -> $T00thread:12efb8e;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,... 8 <- $qThreadStopInfo12efb90#f4 9 -> $T00thread:12efb8f;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,... 10 <- $qThreadStopInfo12efb91#f5 11 -> $T00thread:12efb90;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,... 12 <- $qThreadStopInfo12efb47#f6 13 -> $T00thread:12efb91;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,... 14 <- $qThreadStopInfo12efb8d#27 15 -> $T05thread:12efb47;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,... 16 <- $p0;thread:12efb8e;#f5 17 -> $T00thread:12efb8d;threads:12efb47,12efb8d,12efb8e,12efb8f,12efb90,12efb91;thread-pcs:10abe83,7ff81b20e2be,7ff81b20e3ea,... response (3) is interpreted as the response to the vCont request at (1). We then make a qThreadStopInfo request (4) and receive a stop packet in response (5). Packet (5) is interpreted as the response to (4) but it actually isn't, note how the thread ID is different, packet (5) is actually a spurious stop packet sent by debug server. From response (5) onward the protocol is desynchronized, none of the response we process are actually the response to the preceding request. This eventually causes a failure at packet (17) which debugserver sent as the response to request (14) but we interpret as the response to (16). Fixes go-delve#3013
|
@polinasok I think I've figured out what the problem is but I also can't get it to happen. If you could do whatever you did last week to make it happen and see if this fixes it, it would help. Thanks. |
|
I will try, but since it doesn't happen every time, I might not know for sure if I don't see it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When we send an interrupt request to debugserver we, sometimes, get one
extra spurious stop packet back.
This stop packet gets interpreted as a response to a qThreadStopInfo request
we make causing the protocol to become desynchronized for a while, until
eventually some kind of error appears.
Here's an example of this problem, distilled from issue #3013:
response (3) is interpreted as the response to the vCont request at (1). We
then make a qThreadStopInfo request (4) and receive a stop packet in
response (5). Packet (5) is interpreted as the response to (4) but it
actually isn't, note how the thread ID is different, packet (5) is actually
a spurious stop packet sent by debug server. From response (5) onward the
protocol is desynchronized, none of the response we process are actually the
response to the preceding request.
This eventually causes a failure at packet (17) which debugserver sent as
the response to request (14) but we interpret as the response to (16).
Fixes #3013