May 2, 2012

dvez43 dvez43
Ant Farmer
323 posts

Crash with QVector and freeing memory?


For the past week I have been trying to track this bug in which is causing my Qt application to crash and have been unsuccessful in finding the source of the corruption.

What I have done is created 2 global QVectors<double> using “extern”, as well as 3 Qwt plots that are plotting what ever is in those vectors every 20 mS on a timer. Meanwhile, a QThread is running at the same time looping at 20 mS as well, populating, resizing, and appending values to the arrays to update the plot on the main thread so it updates realtime.

I am only allowing 30 seconds worth of data to be displayed at all times on all three plots, and once the 30 seconds has been met, I clear the arrays and start appending again in a loop…

30 seconds, with 20 mS refresh, the counter will have to reach 1500 when it needs to refresh…so my counter is from 0 to 1500

Here is the code in the thread that handles the resizing and clearing ect.. ect. ect.

  1.     // check if the packet counter is maxed for the graph
  2.     if (p_counter >= 1500){ // check packet counter
  4.         // clear the data
  5.         xDataGlobal.clear();
  6.         xAxisGlobal.clear();
  8.         // resize arrays
  9.         xDataGlobal.resize(0);
  10.         xAxisGlobal.resize(0);
  12.         p_counter = 1;  // clear packet counter
  13.     }
  15.     // check values
  16.     if (typeid(xVal) == typeid(double)){
  17.         // append data to packets
  18.         xDataGlobal.resize(p_counter + 1);
  19.         xAxisGlobal.resize(p_counter + 1);
  20.         xDataGlobal[p_counter] = xVal;
  21.         xAxisGlobal[p_counter] = (double)p_counter;
  23.         // increment the packet counter
  24.         p_counter++;    // increment packet counter
  25.     }
  26.     else {
  27.         qDebug() << "type id error";
  28.     }

This code is in a loop every 20 mS…
Now on the main thread, the 3 graphs are being updated using the QwtPlot::timerEvent in which is triggering every 20 mS and setting the data to a QwtPlotCurves as shown below

  1. void Plot::timerEvent(QTimerEvent *event)
  2. {
  3.     if (event->timerId() == d_timerId){
  4.         setCurveData(xDataGlobal, xAxisGlobal);
  5.         replot();
  6.         return;
  7.     }
  8.     QwtPlot::timerEvent(event);
  9. }
  11. /*
  12. //  set the curve data
  13. */
  14. void Plot::setCurveData(QVector<double> xData, QVector<double> xAxisData)
  15. {
  16.     d_curveX->setSamples(xAxisData, xData);
  17. }

At random times, if I have this application running in debug mode, or release, within an hour or two it crashes (in consistant on the timing though…) and I am unable to figure out why. The crash is difficult to pin point in the crash log and the debugger but it always seems to point to a bad alloc or a QVector on the last couple arguments in the stack.

The most recent crash, I opened the application up in the MSVC2008 debugger when it gave me the option and it showed the free.c file for deleting allocated memory. This is the crash line

  1. #endif  /* CRTDLL */
  2.         else    //  __active_heap == __SYSTEM_HEAP
  3. #endif  /* _WIN64 */
  4.         {
  5.             retval = HeapFree(_crtheap, 0, pBlock);
  6.             if (retval == 0) // says it crashes right here and that retval is invalid
  7.             {
  8.                 errno = _get_errno_from_oserr(GetLastError());
  9.             }
  10.         }
  11. }

From the Qt documentation, clear() frees all of the allocated memory, and resize also removes any extra allocated memory not being used…Am I pushing the QVector to hard? or does anyone have any tips on helping solve this crash? I feel its a memory error…

My system is running Windows 7 using msvc2008 in the QtCreator envoirnment

6 replies

May 2, 2012

Volker Volker
Ant Farmer
5331 posts

I don’t see any mutexes protecting your vector from being read while the thread is writing to them. It’s no surprise that your application crashes. If your GUI reads the vector while at the same time the thread writes to it, it could be that the memory that is used to store the values is released and no longer used for the vector but for something else.

May 3, 2012

dvez43 dvez43
Ant Farmer
323 posts

My first thought was that, but if I have a global QVector in globals.h and globals.cpp as shown:

  1. #include "globalexterns.h"
  3. QVector<double> xDataGlobal;
  4. QVector<double> xAxisGlobal;
  5. double xVal;

  1. extern QVector<double> xDataGlobal;
  2. extern QVector<double> xAxisGlobal;
  3. extern double xVal;

I thought they were thread safe. But now that I think about the fact that when my de-allocations and allocations happen, Qwt could be stepping on the memory somewhere internally, which would only make the xVal double thread safe.

I have added the mutex’s and will see how it goes. I would just think that the trip up would happen more often then it is if it was stepping on the de-allocated memory somewhere due to the timing and how fast I am updating that array, as well as the plot. But time will tell!

Thank you Volker!

May 3, 2012

Volker Volker
Ant Farmer
5331 posts

It doesn’t matter if a data structure is global or part of an object. If you write to it while another thread is reading it, that cries for disaster.

Not even the single double is thread safe without a mutex!

May 3, 2012

dvez43 dvez43
Ant Farmer
323 posts

I actually ran a test over night and it did actually crash again even with the mutex’s… what I find weird is when the debugger crashes and shows the stack, and on both of my threads I was inside my lock on each side, which technically should be impossible since I believe the QMutex’s are blocking correct? Unless I am implementing them wrong. So if I lock one, the other will wait until it is unlocked and vise versa?

Heres what it looks like.

20mS thread loop:

  1.     // lock mutex
  2.     memoryMutex.lock();
  4. // check if the packet counter is maxed for the graph
  5.     if (p_counter >= 1500){ // check packet counter
  7.         // clear the data
  8.         xDataGlobal.clear();
  9.         xAxisGlobal.clear();
  11.         // resize arrays
  12.         xDataGlobal.resize(0);
  13.         xAxisGlobal.resize(0);
  15.         p_counter = 1;  // clear packet counter
  16.     }
  18.     // check values
  19.     if (typeid(xVal) == typeid(double)){
  20.         // append data to packets
  21.         xDataGlobal.resize(p_counter + 1);
  22.         xAxisGlobal.resize(p_counter + 1);
  23.         xDataGlobal[p_counter] = xVal;
  24.         xAxisGlobal[p_counter] = (double)p_counter;
  26.         // increment the packet counter
  27.         p_counter++;    // increment packet counter
  28.     }
  29.     else {
  30.         qDebug() << "type id error";
  31.     }
  33.     // unlock mutex
  34.     memoryMutex.unlock();

main gui thread:

  1. /*
  2. //     timer trigger 20 mS
  3. */
  4. void Plot::timerEvent(QTimerEvent *event)
  5. {
  6.     if (event->timerId() == d_timerId){
  7.         // lock mutex
  8.         memoryMutex.lock();
  10.         setCurveData(xDataGlobal, xAxisGlobal);
  12.         // unlock mutex
  13.         memoryMutex.unlock();
  15.         replot();
  16.         return;
  17.     }
  18.     QwtPlot::timerEvent(event);
  19. }
  21. /*
  22. //  set the curve data
  23. */
  24. void Plot::setCurveData(QVector<double> xData, QVector<double> xAxisData)
  25. {
  26.     d_curveX->setSamples(xAxisData, xData);
  27. }


  1. extern QVector<double> xDataGlobal;
  2. extern QVector<double> xAxisGlobal;
  3. extern double xVal;
  4. extern QMutex memoryMutex;


  1. #include "globalexterns.h"
  3. QVector<double> xDataGlobal;
  4. QVector<double> xAxisGlobal;
  5. double xVal;
  6. QMutex memoryMutex;

It crashed on the setCurveData() function (shown from the debugger assembly) but when I look at the debugger output, it looks like in both of the threads, it crashed between the lock() and unlock()…on BOTH threads? So thread 1 locked, and thread 2 locked, with the same global QMutex. Is this possible??

May 3, 2012

Jeroentje@home Jeroentje@ho..
Robot Herder
949 posts

Two things that come to mind, but using a 20msec timer is very tricky! When using Windows timers below 50msec are very unreliable and the 20msec isn’t guaranteed. Also for the GUI only about 25fps are needed, so I would suggest lowering the timer to around 40 msec. That might free some processor time and handling between the threads. You can check if the 20msec is achieved using the every time you run the timer.

  1. qDebug << QTime::currentTime.toString();

Also it is bad practice to use the global variables. It is called “Global Namespace polution” and should be avoided in object orientated programming.
Hope that lowering the timer increases the reliability of your program.


Greetz, Jeroen

May 3, 2012

dvez43 dvez43
Ant Farmer
323 posts

I am not actually using a timer :) I wish this was the case though!

I have an while loop like so:

  1. void newThread::run()
  2.     while (t_thread){   // inifinite loop
  4.     ... // do things
  5.     ... // do things
  7.     msleep(18);
  8.     }
  9. }

I have calculated that it takes about 2 mS to execute the code that I am doing using the Qt mS timer. On application close, I just toggle the boolean and wait for the thread to finish cleanly before I terminate.

my background has been C all through school mainly for mp’s as well as the linux OS, so the object oriented programming in C++/Qt is new to me this year and i’m still learning “its ways” :)

And from what Volker has stated before, does Qt allocate memory differently that what the underlying c++ would do for using standard c++ types (doubles, ints, ect.)? I can understand if the memory was being tampered with, but the memory location of the single double should be able to be read from anywhere, anytime, from whomever if it does indeed exist. I might be wrong since I am not sure what Qt does in the background or how it deals with it.

  ‹‹ [Solved] Undefined reference to vtable - class in main.cpp      [SOLVED] QVariant: float, type = 135 broken in 4.8.0 ? ››

You must log in to post a reply. Not a member yet? Register here!