This is the mail archive of the gdb-prs@sourceware.org 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]

[Bug remote/14786] New: thread list returned by qfThreadInfoclobbered by g packet


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.


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