Part of text not sent to device

[Michael Jørgensen]

Steps to reproduce:

I'm connecting to a FTDI device (FT2232) over USB using the following command line:

picocom -f h -b 115200 /dev/ttyUSB1

I then copy-paste a large text file (ca. 72 kbytes) into stdin. Almost every time, parts of the text does not get sent to the device. Usually, the missing part is the last 1500 characters or so. The exact amount of missing characters varies each time, but is usually within +/- 50 % of the number 1500.

Attempts at debugging / isolating the problem:

I've checked using the tool strace that the entire text file does indeed get read from stdin (file descriptor 0) and that parts of the text is NOT getting sent to the serial device (file descriptor 3).

I've attached the complete log file obtained by running the command

strace picocom -f h -b 115200 /dev/ttyUSB1 2>&1 | tee log

In the log file the last reads from file descriptor 0 are:

read(0, "0", 1) = 1
read(0, "x", 1) = 1
read(0, "9", 1) = 1
read(0, "5", 1) = 1
read(0, "1", 1) = 1
read(0, "5", 1) = 1
read(0, " ", 1) = 1
read(0, "0", 1) = 1
read(0, "x", 1) = 1
read(0, "0", 1) = 1
read(0, "0", 1) = 1
read(0, "0", 1) = 1
read(0, "0", 1) = 1
read(0, "\r", 1) = 1
read(0, "\5", 1) = 1
read(0, "\1", 1) = 1
read(0, "\30", 1) = 1

This does indeed correspond to the end of the input text file.

The last writes to file descriptor 3 are:

write(3, "0x9481 0x000E\r0x9482 0x00A0\r0x94"..., 509) = 509
write(3, "\5", 1) = 1

It's not entirely clear here, but these log entries match the behaviour seen on the device and confirm that parts of the input file is not sent on the serial port.

Furthermore, I've traced the entire serial traffic on the USB port using usbmon and there again confirm that the last 1500 or so characters are missing.

Additional information:

I'm running on Ubuntu 18.04.5 LTS. The version of picocom I'm using is:

picocom v2.2

Compiled-in options:
  TTY_Q_SZ is 32768
  USE_FLOCK is enabled
  LINENOISE is enabled
  HISTFILE is: .picocom_history

[Michael Jørgensen (mjoergen)]

More specific details:

The text file I'm copy-pasting to stdin is 75572 bytes long.

The total text being transferred consists of the two characters "ml", the text file, and then the control character "^E", i.e. a total of 75575 characters.

Looking through the log file and adding up all the byte counts of writing to file descriptor 3 gives the total sum: 72537 characters. In other words, more than 3000 characters are missing.

Examining the log file some more shows that most of the 4377 different writes to file descriptor 3 consists of just two characters. However, the last 20 or so writes are much larger:

write(3, "3\r", 2) = 2
write(3, "0x8272 0xFFAA\r0x8273 0x0002\r0x82"..., 149) = 149
write(3, "FFA8\r0x827D 0x0003\r0x827E 0xFFA0"..., 207) = 207
write(3, " 0xCF80\r0x828C 0xAAAA\r0x828D 0xF"..., 372) = 372
write(3, "0x82A6 0x0002\r0x82A7 0xE000\r0x82"..., 790) = 790
write(3, " 0xFFAB\r0x82DF 0x0002\r0x82E0 0xE"..., 2095) = 2095
write(3, "x8374 0x0002\r0x8375 0xE000\r0x837"..., 4745) = 4352
write(3, "\r0x84AB 0xC904\r0x84AC 0xFFAB\r0x8"..., 10438) = 4608
write(3, "x85F4 0xC10C\r0x85F5 0xFFAB\r0x85F"..., 11520) = 4608
write(3, "73D 0xFFF8\r0x873E 0x003F\r0x873F "..., 11520) = 4608
write(3, "6 0x003F\r0x8887 0xFFFF\r0x8888 0x"..., 11520) = 4608
write(3, "0x4321\r0x89D0 0x0001\r0x89D1 0x43"..., 11520) = 4608
write(3, "0027\r0x8B19 0xC23E\r0x8B1A 0x8B48"..., 11520) = 4608
write(3, "11\r0x8C62 0x0F80\r0x8C63 0x8765\r0"..., 11520) = 4608
write(3, "\r0x8DAB 0xFFAB\r0x8DAC 0x0020\r0x8"..., 11520) = 4608
write(3, "x8EF4 0xE000\r0x8EF5 0xE000\r0x8EF"..., 11520) = 4608
write(3, "03D 0x00A0\r0x903E 0xCFA0\r0x903F "..., 11520) = 4608
write(3, "6 0x0F82\r0x9187 0x3210\r0x9188 0x"..., 9725) = 4608
write(3, "0x0F82\r0x92D0 0x4567\r0x92D1 0x0F"..., 5117) = 4608
write(3, "0x9481 0x000E\r0x9482 0x00A0\r0x94"..., 509) = 509
write(3, "\5", 1) = 1

[Michael Jørgensen (mjoergen)]

I tried compiling the latest source code (version 3.1) of picocom from https://github.com/npat-efault/picocom and then I can't reproduce the error.

Then I tried again with the original (packaged version 2.2) of picocom and the failure appears again.

So it seems like a bug in picocom was fixed between versions 2.2 and 3.1.