internal-error: target_xfer_partial: Assertion `*xfered_len > 0' failed

internal-error: target_xfer_partial: Assertion `*xfered_len > 0' failed

[Christo]

I'm writing a gdbserver that debugs AVR microcontrollers through the debugWIRE protocol. During
debugging sessions avr-gdb sometimes generates an error.  From the info below the error appears
to be an unexpected length for a reply, possibly caused by receiving the start for a new message
before the end of a previous message(?).

I suspect that it may have something to do with the remote serial protocol implementation on my
side, but cannot figure out what.  Here is a sample gdb session of a simple program (with debug
info) loaded into gdb (program is already loaded in microcontroller), the program is continued
without break points, the program is interrupted by Ctrl+C.  During the subsequent transfer of
memory content the error is triggered (often, but not always):

[I interrupt the running code in gdb with Ctrl+C}
Program received signal SIGINT, Interrupt.
Sending packet: $m80015e,2#2e...Ack
Packet received: 0030
Sending packet: $m50,10#5f...Ack
Saw new packet start in middle of old one
Timed out.
Timed out.
DELAY_MS (Ignoring packet error, continuing...
../../src/gdb/target.c:1376: internal-error: target_xfer_partial: Assertion `*xfered_len > 0'
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit
this debugging session? (y or n)

The corresponding traffic from the gdbserver RSP log:
19:08:04.421  Ctrl+C received
19:08:04.533  <-
$T0200:12;01:00;02:08;03:00;04:00;05:80;06:10;07:09;08:E2;09:01;0A:00;0B:41;0C:00;0D:00;0E:00;0F
:40;10:14;11:00;12:10;13:02;14:0D;15:20;16:00;17:00;18:09;19:00;1A:2A;1B:00;1C:84;1D:00;1E:86;1F
:00;20:00;21:5D01;22:7C000000;#98
19:08:04.534  -> m72,a
19:08:04.548  <- $8115910531F0AFECB7E0#75
19:08:04.577  -> qL1160000000000000000
19:08:04.577  <- $qM0010000000000000000#4F
19:08:04.621  -> m80015e,2
19:08:04.628  <- $0030#C3
19:08:04.665  -> m50,10
19:08:04.677  <- $0ED0BC9A18BA20E126BB8AEF912D09D0#59

I don't see any response errors or overlapping replies on the server side...

I get this error both on avr-gdb 7.10.1 (Installed by Linux Mint) and gdb 8.0 (which I compiled
from source).  I don't see this error if I don't load the file with debug info into gdb. Also no
error if I use gdb 7.0.1 or 6.6 (both also compiled by me).

Any hints or ideas of where or what the problem may be?

Regards,
Christo

Re: internal-error: target_xfer_partial: Assertion `*xfered_len > 0' failed

[Christo]

On Wed, 2018-05-30 at 22:09 +0200, Christo wrote:
> I get this error both on avr-gdb 7.10.1 (Installed by Linux Mint) and gdb 8.0 (which I
> compiled
> from source).  I don't see this error if I don't load the file with debug info into gdb. Also
> no
> error if I use gdb 7.0.1 or 6.6 (both also compiled by me).

I tested on gdb 8.1 compiled for AVR and still see "Saw new packet start in middle of old one"
message, but now gdb seems to ignore the packet error and just continue without the internal
error message.  I still would like to know where the problem is so that it can be fixed, else
gdb may end up with incomplete information of the flash memory content on the controller.

Re: internal-error: target_xfer_partial: Assertion `*xfered_len > 0' failed

[Christo]

On Fri, 2018-06-01 at 06:36 +0200, Christo wrote:
> On Wed, 2018-05-30 at 22:09 +0200, Christo wrote:
> > 
> > I get this error both on avr-gdb 7.10.1 (Installed by Linux Mint) and gdb 8.0 (which I
> > compiled
> > from source).  I don't see this error if I don't load the file with debug info into gdb.
> > Also
> > no
> > error if I use gdb 7.0.1 or 6.6 (both also compiled by me).
> I tested on gdb 8.1 compiled for AVR and still see "Saw new packet start in middle of old one"
> message, but now gdb seems to ignore the packet error and just continue without the internal
> error message.  I still would like to know where the problem is so that it can be fixed, else
> gdb may end up with incomplete information of the flash memory content on the controller.

I suspect that the culprit was on my server side, where I transmitted responses as Pascal
strings, which prepends the length of the string to the data stream.  I suspect that gdb
filtered out the extra data at the start of the replies successfully in many (but not all)
cases.  Anyway, sending the replies as byte streams without a length prefix seems to have
eliminated my problem.