memory corruption when serial input overflows

["H. Henning Schmidt" <Henning dot Schmidt at lynx-technik dot com>]

I have run into a problem with the serial input (e.g. "COM1").
This is on WinXp Pro and cygwin 1.3.22.
In the archives there are some references to this (or a similar?) issue. 
I got the idea that it is known that there are issues ... but nobody is 
working on them at this time.

Here is a testcase that easily provokes an error, which to my 
understanding is some form of memory corruption around the data 
associated with the open file descriptor.
You need to run this testcase and connect the RX and TX lines of the 
serial port COM1. This will make all the data written out by this 
program be re-directed to the serial input. The program never calls 
read() on the input though and thus provokes an overflow.

Now that I have identified the problem I can work around it (basically 
by providing a separate thread that does nothing but pulling bytes off 
the channel and putting them into some private fifo of mine). Just 
thought I might just as well share my test-case with you. Maybe someone 
has an idea how to *really* fix this. I guess loosing/dropping some data 
on overflow would be preferrable to corrupting the memory ...

;Henning

// file main.cpp ---------------------------------------------------
#include <stdio.h>
#include <termios.h>
#include <unistd.h>
#include <fcntl.h>

int
main (int argc, char *argv[])
{
  // open serial port
  int fd = open ("/dev/com1", O_RDWR);

  // set baud rate
  struct termios _termios;
  cfsetospeed (&_termios, B38400);
  cfsetispeed (&_termios, B38400);
  tcsetattr (fd, TCSANOW, &_termios);

  while (1)
  {
     // verification of "loop still looping"
     fprintf (stderr, ".");

     // don't toast my CPU ...
     usleep (100);

     // write some data to the serial output
     char data = 0x00;
     ::write (fd, &data, 1);

     // never read from the serial input.
     //
     // if you connect the RX/TX lines (pin 2 and 3 on the COM SubD9
     // connector), this will generate some kind of overflow and
     // result in memory corruption
     //
     // on my machine this is easily recognizable by the fact that
     // (a) the "loop still running" does pump anymore and (b) the
     // "Windows Task Manager" (CTRL-ALT-DEL on WinXP) shows CPU
     // activity of 100%. This is somewhere around 10% while running
     // normally (RX/TX not connected).
  }
}
// end of file ----------------------------

# file Makefile ---------------------------
bustSerialPort: main.o
   g++ -o $@ $^

%.o : %.cpp
   g++ -o $@ -c $^
# end of file -----------------------------




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/