ReceiveTempSMS
/
Sweden-Number
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Fixed protocol packet handling when winedbg is too slow to answer.

This commit is contained in:
Eric Pouech 2003-01-07 19:45:40 +00:00 committed by Alexandre Julliard
parent 4bb180c9fa
commit fde8806673
1 changed files with 64 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
programs/winedbg/gdbproxy.c
View File

@ -20,6 +20,10 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
/* Protocol specification can be found here:
* http://sources.redhat.com/gdb/onlinedocs/gdb_32.html
*/
#include "config.h"
#include <assert.h>
@ -1788,6 +1792,7 @@ static BOOL extract_packets(struct gdb_context* gdbctx)
unsigned char in_cksum, loc_cksum;
char* ptr;
enum packet_return ret = packet_error;
int num_packet = 0;
while ((ret & packet_last_f) == 0)
{
@ -1814,6 +1819,7 @@ static BOOL extract_packets(struct gdb_context* gdbctx)
loc_cksum = checksum(gdbctx->in_buf + 1, plen);
if (loc_cksum == in_cksum)
{
if (num_packet == 0) {
int i;
ret = packet_error;
@ -1857,6 +1863,24 @@ static BOOL extract_packets(struct gdb_context* gdbctx)
/* if this fails, we'll have to use POLLOUT...
*/
gdbctx->out_len = 0;
num_packet++;
}
else
{
/* FIXME: if we have in our input buffer more than one packet,
* it's very likely that we took too long to answer to a given packet
* and gdb is sending us again the same packet
* We simply drop the second packet. This will lower the risk of error,
* but there's still some race conditions here
* A better fix (yet not perfect) would be to have two threads:
* - one managing the packets for gdb
* - the second one managing the commands...
* This would allow us also the reply with the '+' character (Ack of
* the command) way sooner than what we do know
*/
if (gdbctx->trace & GDBPXY_TRC_LOWLEVEL)
fprintf(stderr, "dropping packet, I was too slow to respond\n");
}
}
else
{