CODEWITHSUNDEEP
c++linuxserial-port
user1623263
user1623263

Reputation: 1

C++ linux application stops the system after long time running. How to find the reason?

I am creating a scientific application, that communicates with two devices (one via USB, one via serial port), takes data from them and present it in GUI. For unknown reason after running for several hours (2-5 maybe?) the whole system is suddenly starting to slow down, and after one or two minutes nothing is responding at all. The only solution then is to restart the PC with power button. The USB port communication is handled by code that came with this device, so it's probably OK. The only hint I have is that reason might be in serial port communication, which I was implementing for the first time. But it may be anything else (e.g. GUI) as well. I'm running it on Scientific Linux 5. To open the serial port, I use:

tti::tti(const char* port)
{
fd = open(port,
        (O_RDWR | O_NOCTTY) & ~O_NONBLOCK); //opening the port
if (fd == -1)
{
    std::cout<<"error in tti::tti(const char* port) while opening port"<<std::endl;
}
else
{
    //setting parameters
    struct termios options; //create the struct
    tcgetattr(fd,&options); //get the current settings of the serial port
    cfsetispeed(&options,B9600); //set read and write speed to 19200 BAUD
    cfsetospeed(&options,B9600);
    options.c_cflag &= ~PARENB; //set no parity
    options.c_cflag &= ~CSTOPB; //set one stop bit
    options.c_cflag &= ~CSIZE; //clear current data size setting
    options.c_cflag |= CS8; //set 8 bit per work
    options.c_cc[VMIN] = 2; //minimum amount of characters to read
    options.c_cc[VTIME] = 10; //amount of time to wait for amount of data specified in VMIN in tenths of a second
    options.c_cflag |= (CLOCAL | CREAD); //don't allow changing of port control + enable the receiver
    if (tcsetattr(fd,TCSANOW,&options)!=0)
    {
        std::cout<<"error in tti::tti(const char* port) while setting options"<<std::endl;
    }
}
}

Then I use this code every ~3 seconds, 4 times in a row:

std::string tti::query(std::string input){
input+=10;

int bytes = 0;

bytes = write(hSerial, input.c_str(), input.size());

if(bytes < 1){
    std::cout<<"error in tti::send(std::string input) "<<std::endl;
    return "error: no bytes written";
}

bytes=0;
const int n=10;
char szBuffer[n +1]={0};
bytes = read(hSerial,szBuffer,n);
bytes = read(hSerial,szBuffer,n);
if(bytes < 1){
    std::cout<<"error in tti::query(std::string input)"<<std::endl;
    return "error: no bytes read";
}

std::string s2(szBuffer);
return s2;

}

Could You give me some advice how to find the reason for this behavior? I tried to run the app with valgrind and I found no memory leaks. I also tried to check the code with cppcheck and found nothing. The problem is that application does not crash - it's running, but not responding. It has never happened in short-time run. The shortest time I waited for it to stop was 2 hours, but I also have run it 2-3 times for longer time without any problems.

Upvotes: 0

Views: 274

Answers (3)

user1623263
user1623263

Reputation: 1

Thank You for Your answers!

I managed to find the source of increasing memory usage. Indeed the "top" command helped me a lot. It turned out, that I was allocating about 1MB per second without deleting it! After a few hours all physical memory of the PC was "eaten" by my application, so it stopped everything. Selectively disabling parts of my code and running "top", I found the part responsible for the problem.

The reason was somewhere else, not in serial port communication. In the application I had 6 objects (instances of the same class) responsible for real-time data plots. One of members of the plot holding class was a pointer to the plot itself. With every GUI refresh, I was overwriting the pointer with new plot object, without deleting the old one. I thought it would be deleted automatically, but I was wrong.

void graphData::updateGraph () {

    delete m_graph; //THIS LINE WAS MISSING
    m_graph = new TGraph(m_xArray.GetSize(),m_xArray.GetArray(),m_yArray.GetArray());

    //(...) some more code in this function
}

Sounds pretty simple, but it took me a week to solve this problem. ;)

Upvotes: 0

dimba
dimba

Reputation: 27581

You can run top in batch mode. In this mode you can save it's output in file to be analized later:

  top -b -n sample_delay_in_sec | tee log.log

This command will print output to console ans save it to log.log file too.

Interesting output can be CPU, Mem, Swap. Of course look if you have some processes using a lot of memory or/and CPU.

Upvotes: 1

Peter
Peter

Reputation: 14937

The app does not have to actually leak memory in order to have memory problems. If you continually allocate more memory to hold the new data, then memory usage will expand without bound (until your system behaves much like you've described), even though you're not actually leaking memory.

First, just watch the memory usage in top or ps. Then, if you can't find the place that uses memory forever without freeing it, you can use the massif tool of valgrind to look at what lines of code are responsible for the current state of the heap.

Upvotes: 4

Related Questions