[Bug remote/11255] New: weirdness in remote serial protocol over loopback

["_deepfire at feelingofgreen dot ru" <sourceware-bugzilla at sourceware dot org>]

The wide picture is that I'm trying to hook up the recently open-sourced
common-db as GDB's backend, using Julian Stecklina's GDB-REMOTE.

The symptom is (with relevant context incrementally added further):

0. GDB command line:
(gdb) cont
Continuing.
Reply contains invalid hex digit 79

1. on message level:
GDB> m80001134,4
<reply 00000000

We see that it doesn't get to actually 'vCont' or 'c', as it tries to
gather secondary information.  OTOH, from gdb-remote's standpoint all is well.

2. as seen on the wire:
06:33:17.349884 IP (tos 0x0, ttl 64, id 51150, offset 0, flags [DF], proto TCP
(6), length 67)
    localhost.47884 > localhost.9000: Flags [P.], cksum 0xfe37 (incorrect ->
0x3a36), seq 141205:141220, ack 5023, win 769, options [nop,nop,TS val 19851201
ecr 19837510], length 15
	0x0000:  4500 0043 c7ce 4000 4006 74e4 7f00 0001  E..C..@.@.t.....
	0x0010:  7f00 0001 bb0c 2328 a137 e67c a13c f245  ......#(.7.|.<.E
	0x0020:  8018 0301 fe37 0000 0101 080a 012e e7c1  .....7..........
	0x0030:  012e b246 246d 3830 3030 3131 3334 2c34  ...F$m80001134,4
	0x0040:  2335 65                                  #5e
06:33:17.356388 IP (tos 0x0, ttl 64, id 43032, offset 0, flags [DF], proto TCP
(6), length 64)
    localhost.9000 > localhost.47884: Flags [P.], cksum 0xfe34 (incorrect ->
0x8d35), seq 5023:5035, ack 141220, win 769, options [nop,nop,TS val 19851203
ecr 19851201], length 12
	0x0000:  4500 0040 a818 4000 4006 949d 7f00 0001  E..@..@.@.......
	0x0010:  7f00 0001 2328 bb0c a13c f245 a137 e68b  ....#(...<.E.7..
	0x0020:  8018 0301 fe34 0000 0101 080a 012e e7c3  .....4..........
	0x0030:  012e e7c1 2430 3030 3030 3030 3023 3830  ....$00000000#80
06:33:17.356416 IP (tos 0x0, ttl 64, id 51151, offset 0, flags [DF], proto TCP
(6), length 52)
    localhost.47884 > localhost.9000: Flags [.], cksum 0xaa4f (correct), ack
5035, win 769, options [nop,nop,TS val 19851203 ecr 19851203], length 0
	0x0000:  4500 0034 c7cf 4000 4006 74f2 7f00 0001  E..4..@.@.t.....
	0x0010:  7f00 0001 bb0c 2328 a137 e68b a13c f251  ......#(.7...<.Q
	0x0020:  8010 0301 aa4f 0000 0101 080a 012e e7c3  .....O..........
	0x0030:  012e e7c3                                ....

Here, it seems that there's nothing to complain about, as well.
Notice, though, how TCP-over-loopback doesn't have checksums.  But that's OK.

3. as seen through GDB-under-GDB goggles:

deepfire@aldebaran:/little/src$ gdb -ex 'break remote.c:5823' --args mips-gdb
-ex 'target extended-remote :9000' -ex 'load /little/src/video.o'GNU gdb (GDB)
7.0-ubuntu
                                               ^^^^^^^^^^^^^ a carefully
selected breakpoint
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/mips-gdb...done.
Breakpoint 1 at 0x8078dc7: file remote.c, line 5823.
(gdb) run
Starting program: /usr/bin/mips-gdb -ex target\ extended-remote\ :9000 -ex load\
/little/src/video.o
[Thread debugging using libthread_db enabled]
GNU gdb (GDB) 7.0.50.20091222-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=mips".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Remote debugging using :9000
0x04040cbc in ?? ()
Loading section .text, size 0xfac8 lma 0x80001000
Ignoring packet error, continuing...
Loading section .data, size 0xaa0 lma 0x80010ad0
Loading section .ctors, size 0x8 lma 0x80011570
Loading section .dtors, size 0x8 lma 0x80011578
Loading section .eh_frame, size 0x4 lma 0x80011580
Loading section .jcr, size 0x4 lma 0x80011584
Loading section .rodata, size 0xd10 lma 0x80011590
Loading section .reginfo, size 0x18 lma 0x800122a0
Start address 0x80001134, load size 70312
Transfer rate: 1 KB/sec, 4687 bytes/write.
============= here our self-inflicted trouble begins...
(gdb) cont
Continuing.

Breakpoint 1, remote_read_bytes (memaddr=2147488052, 
    myaddr=0xbfffee24
"\200\336\005\b\024\062<\b\230\006E\b\200\322D\b\024\062<\bX\356\377\277\262\036\006\b`p,\b\024\062<\b
2<\b\024\062<\b\300\356\377\277 2<\b\230\356\377\277L\f\006\b\024\062<\b
2<\b\210\356\377\277\200\303\023\b\020\244", len=4) at remote.c:5823
5823	      getpkt (&rs->buf, &rs->buf_size, 0);
(gdb) s
getpkt (buf=0x8373160, sizeof_buf=0x8373164, forever=0) at remote.c:6495
6495	{
(gdb) 
6499	}
(gdb) 
getpkt (buf=0x80001134, sizeof_buf=0xffffffff, forever=-1073746396) at remote.c:6498
6498	  timed_out = getpkt_sane (buf, sizeof_buf, forever);
(gdb) 
getpkt_sane (buf=0x8373160, sizeof_buf=0x8373164, forever=0) at remote.c:6649
6649	{
(gdb) 
6650	  return getpkt_or_notif_sane_1 (buf, sizeof_buf, forever, 0);
(gdb) 
getpkt_or_notif_sane_1 (buf=0x8373160, sizeof_buf=0x8373164, forever=0,
expecting_notif=0) at remote.c:6515
6515	{
(gdb) 
6516	  struct remote_state *rs = get_remote_state ();
(gdb) n
6526	  strcpy (*buf, "timeout");
(gdb) 
6516	  struct remote_state *rs = get_remote_state ();
(gdb) 
6524	  rs->cached_wait_status = 0;
(gdb) print *buf
$1 = 0x8468b58 "m80001134,4"
(gdb) n
6526	  strcpy (*buf, "timeout");
(gdb) 
6528	  if (forever)
(gdb) print *buf
$2 = 0x8468b58 "timeout"
(gdb) n
6530	  else if (expecting_notif)
(gdb) 
6534	    timeout = remote_timeout;
(gdb) 
6556		    c = readchar (timeout);
(gdb) 
6557		  while (c != SERIAL_TIMEOUT && c != '$' && c != '%');
(gdb) print c
$3 = 138840930
(gdb) n
6556		    c = readchar (timeout);
(gdb) 
6557		  while (c != SERIAL_TIMEOUT && c != '$' && c != '%');
(gdb) print c
$4 = 36
(gdb) n
6578		      val = read_frame (buf, sizeof_buf);
(gdb) print *buf
$5 = 0x8468b58 "timeout"
               ^^^^^^^^^ that's okay, the default poisoning payload is on its place
(gdb) n
6579		      if (val >= 0)
(gdb) print *buf
$6 = 0x8468b58 "OK"
               ^^^^ now, what's this?  we certainly haven't had that on the wire...
...but what if...
Right, let's look at the history, as seen by GDB-REMOTE:
|GDB>
M80011590,d10:43000000e00a018000000000000000002f6465762f7474795330000032380000303300003133000031350000353000001f0000001c0000001f0000001e0000001f0000001e0000001f0000001f0000001e00|00001f0000001e0000001f000000000000001f0000003b0000005a0000007800000097000000b5000000d4000000f300000011010000300100004e0100001f0000001c0000001f0000001e0000001f0000001e0000001f0000001f0|000001e0000001f0000001e0000001f0000001f...continued
|<reply OK
|GDB> M800122a0,18:000000a00000000000000000000000000000000090150180
|<reply OK
|GDB> P22=80001134
|<reply OK
|GDB> m80001134,4
|<reply 00000000
Yeah, looks like we have a component of a theory.

Now, let's take the backtrace:

(gdb) bt
#0  getpkt_or_notif_sane_1 (buf=0x8373160, sizeof_buf=0x8373164, forever=0,
expecting_notif=0) at remote.c:6579
#1  0x08076df2 in getpkt_sane (buf=0x2, sizeof_buf=0x0, forever=137834848) at
remote.c:6650
#2  0x08078de1 in remote_read_bytes (memaddr=2147488052, 
    myaddr=0xbfffee24
"\200\336\005\b\024\062<\b\230\006E\b\200\322D\b\024\062<\bX\356\377\277\262\036\006\b`p,\b\024\062<\b
2<\b\024\062<\b\300\356\377\277 2<\b\230\356\377\277L\f\006\b\024\062<\b
2<\b\210\356\377\277\200\303\023\b\020\244", len=4) at remote.c:5823
#3  0x08079986 in remote_xfer_partial (ops=0x8373340,
object=TARGET_OBJECT_MEMORY, annex=0x0, 
    readbuf=0xbfffee24
"\200\336\005\b\024\062<\b\230\006E\b\200\322D\b\024\062<\bX\356\377\277\262\036\006\b`p,\b\024\062<\b
2<\b\024\062<\b\300\356\377\277 2<\b\230\356\377\277L\f\006\b\024\062<\b
2<\b\210\356\377\277\200\303\023\b\020\244", writebuf=0x0,
offset=18446744071562072372, len=4) at remote.c:7489
#4  0x0813ca3d in memory_xfer_partial (ops=0x8373340,
object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0xbfffee24, writebuf=0x0,
offset=18446744071562072372, len=4) at target.c:1315
#5  target_xfer_partial (ops=0x8373340, object=TARGET_OBJECT_MEMORY, annex=0x0,
readbuf=0xbfffee24, writebuf=0x0, offset=18446744071562072372, len=4) at
target.c:1383
#6  0x0813d28b in target_read_partial (ops=0x2, object=TARGET_OBJECT_AVR,
annex=0x8373160 "X\213F\b", 
    buf=0xbfffee24
"\200\336\005\b\024\062<\b\230\006E\b\200\322D\b\024\062<\bX\356\377\277\262\036\006\b`p,\b\024\062<\b
2<\b\024\062<\b\300\356\377\277 2<\b\230\356\377\277L\f\006\b\024\062<\b
2<\b\210\356\377\277\200\303\023\b\020\244", offset=18446744072635805220,
len=3221220900) at target.c:1659
#7  0x0813d79b in target_read (ops=0x8373340, object=TARGET_OBJECT_MEMORY,
annex=0x0, 
    buf=0xbfffee24
"\200\336\005\b\024\062<\b\230\006E\b\200\322D\b\024\062<\bX\356\377\277\262\036\006\b`p,\b\024\062<\b
2<\b\024\062<\b\300\356\377\277 2<\b\230\356\377\277L\f\006\b\024\062<\b
2<\b\210\356\377\277\200\303\023\b\020\244", offset=18446744071562072372, len=4)
at target.c:1686
#8  0x0813df5a in target_read_memory (memaddr=18446744069414584322, 
    myaddr=0xbfffee24
"\200\336\005\b\024\062<\b\230\006E\b\200\322D\b\024\062<\bX\356\377\277\262\036\006\b`p,\b\024\062<\b
2<\b\024\062<\b\300\356\377\277 2<\b\230\356\377\277L\f\006\b\024\062<\b
2<\b\210\356\377\277\200\303\023\b\020\244", len=4) at target.c:1459
#9  0x0806b5e3 in mips_stub_frame_sniffer (self=0x82c7060, this_frame=0x83c3214,
this_cache=0x83c3220) at mips-tdep.c:2293
#10 0x08061eb2 in frame_unwind_find_by_frame (this_frame=0x83c3214,
this_cache=0x83c3220) at frame-unwind.c:102
#11 0x08060c4c in get_frame_id (fi=0x83c3214) at frame.c:331
#12 0x08119a60 in make_cleanup_restore_current_thread () at thread.c:1030
#13 0x080665e8 in save_current_space_and_thread () at progspace.c:480
#14 0x080c1712 in insert_breakpoint_locations () at breakpoint.c:1587
#15 0x081143bc in proceed (addr=18446744073709551615,
siggnal=TARGET_SIGNAL_DEFAULT, step=0) at infrun.c:1804
#16 0x0810908b in continue_1 (all_threads=0) at infcmd.c:668
#17 0x081098bd in continue_command (args=0x0, from_tty=1) at infcmd.c:760
#18 0x08057d31 in execute_command (p=0x838d394 "", from_tty=1) at top.c:450
#19 0x08121b48 in command_handler (command=0x838d390 "cont") at event-top.c:511
#20 0x081227c3 in command_line_handler (rl=0x8449d70 "") at event-top.c:736
#21 0x0822478f in rl_callback_read_char () at callback.c:205
#22 0x08121c8b in rl_callback_read_char_wrapper (client_data=0x0) at event-top.c:178
#23 0x081217ae in handle_file_event (data=...) at event-loop.c:812
#24 0x08120b0c in process_event () at event-loop.c:394
#25 0x081216f2 in gdb_do_one_event (data=0x0) at event-loop.c:459
#26 0x0811c0e3 in catch_errors (func=0x8121510 <gdb_do_one_event>,
func_args=0x0, errstring=0x82c7c32 "", mask=6) at exceptions.c:510
#27 0x080a2144 in tui_command_loop (data=0x0) at ./tui/tui-interp.c:153
#28 0x0811c71f in current_interp_command_loop () at interps.c:291
#29 0x0804ef2b in captured_command_loop (data=0x0) at ./main.c:226
#30 0x0811c0e3 in catch_errors (func=0x804ef20 <captured_command_loop>,
func_args=0x0, errstring=0x82c7c32 "", mask=6) at exceptions.c:510
#31 0x0804e576 in captured_main (data=0xbffff354) at ./main.c:902
#32 0x0811c0e3 in catch_errors (func=0x804de20 <captured_main>,
func_args=0xbffff354, errstring=0x82c7c32 "", mask=6) at exceptions.c:510
#33 0x0804dbf1 in gdb_main (args=0xbffff354) at ./main.c:911
#34 0x0804dbb5 in main (argc=138840920, argv=0x8000) at gdb.c:33

Now, as an icing on the cake, if I run this gdb-under-gdb session from under Emacs,
the bug disappears!

-- 
           Summary: weirdness in remote serial protocol over loopback
           Product: gdb
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: remote
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: _deepfire at feelingofgreen dot ru
                CC: gdb-prs at sourceware dot org
 GCC build triplet: i686-gnu-linux
  GCC host triplet: i686-gnu-linux
GCC target triplet: mips-unknown-elf


http://sourceware.org/bugzilla/show_bug.cgi?id=11255

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.