This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug remote/14786] New: thread list returned by qfThreadInfoclobbered by g packet
- From: "richard_sharman at mitel dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 30 Oct 2012 13:46:14 +0000
- Subject: [Bug remote/14786] New: thread list returned by qfThreadInfoclobbered by g packet
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=14786
Bug #: 14786
Summary: thread list returned by qfThreadInfo clobbered by g
packet
Product: gdb
Version: 7.5
Status: NEW
Severity: normal
Priority: P2
Component: remote
AssignedTo: unassigned@sourceware.org
ReportedBy: richard_sharman@mitel.com
Classification: Unclassified
Created attachment 6711
--> http://sourceware.org/bugzilla/attachment.cgi?id=6711
Output from $ diff -c remote.c.orig remote.c > Patch
Function remote_threads_info in remote.c gets a list of threads from
the target and is supposed call remote_notice_new_inferior for each of
them. However, while processing one the list of threads (in rs->buf)
can be clobbered by other calls to putpkt and getpk that use rs->buf.
Some calls (e.g. qAttached) only change the first few bytes of rs->buf
but under some cases send_g_packet can be called and this overwrites
many bytes.
gdb version: 7.5
remote target: a locally written program using an ethernet socket to
communicate with gdb and talking to a target
scenario:
- initially no threads are known by gdb.
- an "info threads" command is given, so gdb sends "fThreadInfo"
- the target replies with at least two threads, e.g. "m19b1e00,19b1ac0l"
- gdb processes the first thread but while in remote_notice_new_inferior
send_g_packet is called clobbering the list of threads in rs->buf
Example:
(gdb) info threads
Sending packet: $qfThreadInfo#bb...Ack
Packet received: m19b1e00,19b1ac0l
Breakpoint 33, remote_threads_info (ops=0xdb41a0 <extended_remote_ops>) at
../../gdb/remote.c:2775
(top-gdb) p bufp
$29 = 0xeabb00 "m19b1e00,19b1ac0l"
(top-gdb) x/s bufp
0xeabb00: "m19b1e00,19b1ac0l"
(top-gdb) n
(top-gdb) n
(top-gdb) p bufp
$30 = 0xeabb08 ",19b1ac0l"
gdb is about to process the first thread, 19b1e00, and then when done
should work on 19b1ac0. However, it asks for the registers for
19b1e00 and when done bufp is no longer valid because it has been
overwritten with the reply to the 'g' packet.
Sending packet: $g#67...Ack
Packet received: 0000000001a5adf000000000000000000000000 <truncated>
now back in remote_threads_info:
(top-gdb) p bufp
$31 = 0xeabb08 "01a5adf", '0' <repeats 193 times>...
(top-gdb) x/s bufp
0xeabb08: "01a5adf", '0' <repeats 193 times>...
A quick workaround is to save a copy of the register list received;
see attached file Patch.
$ diff -c remote.c.orig remote.c > Patch
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.