This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[commit/ob] remote: avoid undefined results in old thread extra info query

Hi guys,

I'm checking in the attached obvious patch.

We were parsing the reply starting at `rs->buf + 2', without checking
if the remote side supports the packet at all, possibly yielding
undefined results.

Here's what you usually get, if the remote doesn's support the query:

 (top-gdb) p rs->buf
 $2 = 0xbe4a60 ""
 (top-gdb) p rs->buf + 2
 $3 = 0xbe4a62 "meout"

That was "timeout" before being clobbered with the remote
replying '\0' --- meaning no support for this optional packet.  By
chance, this string happens to have the property of not producing
any warning/error inside remote_unpack_thread_info_response.  If it
had a parseable integer in it, it would --- I tripped on
this while implementing remote non-stop support.

Pedro Alves
2008-10-08  Pedro Alves  <>

	* remote.c (remote_get_thread_info): If the remote doesn't support
	the query, bail out.

 gdb/remote.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: src/gdb/remote.c
--- src.orig/gdb/remote.c	2008-10-08 15:20:17.000000000 +0100
+++ src/gdb/remote.c	2008-10-08 15:24:00.000000000 +0100
@@ -1831,6 +1831,10 @@ remote_get_threadinfo (threadref *thread
   pack_threadinfo_request (rs->buf, fieldset, threadid);
   putpkt (rs->buf);
   getpkt (&rs->buf, &rs->buf_size, 0);
+  if (rs->buf[0] == '\0')
+    return 0;
   result = remote_unpack_thread_info_response (rs->buf + 2,
 					       threadid, info);
   return result;

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]