1

I have a C++ Qt static library with two classes - dataprocthread and calcvalue. In the first one, when I call a method from an instance of calcvalue, pointer this (which references to dataprocthread class) suddenly becomes null.

This is dataprocthread.h:

class DataProcThread : public QThread
{
    Q_OBJECT

    public:
        DataProcThread(int sarray[9], int val);

    signals:
        workDone(int result);

    private:            
        int _sarray[9];
        int _val;
        void run();
};

dataprocthread.cpp:

DataProcThread::DataProcThread(int sarray[9], int val)
{
    for (int x = 0; x < 9; x++)
    {
        _sarray[x] = sarray[x];
    }
    _val = val;
}

void DataProcThread::run()
{
    CalcValue* cv = new CalcValue();
    int myval = 0;
    for (int i = 0; i < 100; i++)
    {
        myval = cv->processData(this->_val);
        if (this->_sarray[0] != myval)
        {
            //do something
        }
    }
    emit workDone(intValue);
}

calcvalue.h:

class CalcValue
{
    public:
        CalcValue();
        int processData(int someval);
};

calcvalue.cpp:

CalcValue::CalcValue()
{
}

int processData(int someval)
{
    //do something and return int value
}

When I run this code, it suddenly recieves signal "Segmentation fault". Using debugger, I found that the problem in DataProcThread::run() function: when I call cv->processData function, all works good. But on the next line (if (this->_sarray[0] != myval)), this pointer becomes null (I can see it in Locals window), therefore, I can't access this->_sarray variable.

In case it is important, that's how I start the thread (from another class outside my library):

DataProcThread* thread = new DataProcThread(sarray, val);
QObject::connect(thread, SIGNAL(workDone(int)), this, SLOT(collectWork(int)));
thread->start();

What I am doing wrong?

ahawkthomas
  • 656
  • 3
  • 13
  • 26
  • i guess `this->_sarray[0]` is null. – Lwin Htoo Ko Apr 02 '13 at 08:44
  • Before `this` becomes `null`, I can see `sarray` values in Locals window. – ahawkthomas Apr 02 '13 at 08:47
  • 3
    Maybe your processData is writing over memory – marcinj Apr 02 '13 at 08:48
  • Hmm, that sounds possible. I'll try to look into this. Can `strcpy`, `char**` or `strtoll` do this? – ahawkthomas Apr 02 '13 at 08:51
  • Are you sure that the `DataProcThread` object hasn't been destroyed already? Or that you're you're not trying to invoke `run` on a null pointer? – jamesdlin Apr 02 '13 at 08:53
  • I don't think so, there are no place that deletes `DataProcThread`. – ahawkthomas Apr 02 '13 at 08:54
  • 2
    If all is well before calling `processData`, and things are broken afterwards, then maybe perhaps `processData` could be possibly doing something suspicious? Just a wild guess. – n. m. could be an AI Apr 02 '13 at 08:57
  • 1
    @ahawkthomas strcpy can, you can eliminate this hypothesis by eliminating code from processData, Visual Studio in debugging mode is able to show you exact line where any buffer overrun happens – marcinj Apr 02 '13 at 08:57
  • 2
    Deleting an object has absolutely nothing to do with a pointer to said object becoming null. One is neither necessary nor sufficient for the other. – n. m. could be an AI Apr 02 '13 at 08:59
  • @n.m. Sorry, I really meant: does some object that's already been destroyed have a member pointing to it. If a debug runtime zeroes freed memory, then that member could have the value 0, and accidentally attempting to invoke a method through that pointer then would lead to a null `this` pointer. – jamesdlin Apr 02 '13 at 10:15

1 Answers1

2

The problem, as was pointed out in comments, took place in processData function: it was writing over memory.

I simply used strncpy instead of strcpy and the problem gone (here is a good explanation about this).

Community
  • 1
  • 1
ahawkthomas
  • 656
  • 3
  • 13
  • 26