Segmentation fault SIGSEGV, what can it be?

StephanWoebbeking

One more bit of information...

I am just about to change to an instance instead of a pointer... then it crossed me, that the "device" is also a pointer to the instance. I don't really see any issue there, but maybe someone else does?

Stephan

StephanWoebbeking

Changed back to use the instance directly and NOT the pointer - the same problem, but already when I do "clear" on the array. Funny is, that the debugger visualizes the QByteArray, its empty (which is ok), but on first access I get the SIGSEGV... Obviously I can't instantiate it then via "new" then...

Stephan

jsulm

Do you mean it crashes at device->rfPower4x1.clear();?
Does device point to a valid instance?

StephanWoebbeking

Yes, that's exactly where I get the segmentation fault. Device is accessible, I use it a lot. The debugger shows the content of rfPower4x1 to be "" / empty, that's fine...

Any ideas?
Stephan

StephanWoebbeking

One more thing. Now I have added "rfPower4x1.clear();" right in the constructor of the device - works perfectly, no problem but "device->rfPower4x1.clear();" crashes shortly after. No destroying access coded as far as I can see it.

Actually, there are some subobjects to the device, five to be exact. All implement the rfPower4x1 field as well, but its never accessed for the subobjects, only in the father object. That's not great design, I was up to consider to change it, but then this fault holds me up and I would like to sort that out before. Partly because I need it right like this but mainly because I want to understand what's going on...

Stephan

jsulm

What happens if you remove device->rfPower4x1.clear();?

StephanWoebbeking

Then, the error occurs consequently at "device->rfPower4x1.append( data );"...

SGaist

Silly question, but did you properly initialize device ? Is it deleted somewhere ?

StephanWoebbeking

Hi SGaist, no, it's not a silly question, but the answer could, potentially, lead to a silly answer. ;)

The device was dynamically initialized with "new" and works fine to all other aspects. So private data is happily accessed in read and write operations as well as method calls. The device is used without problems before and after the questionable calls to the rfPower4x1 field. Also the subobjects are working fine, its just this QByteArray...

Stephan

StephanWoebbeking

Hi, back to the multithreading again. I figured, that indeed the data I am processing comes back asynchronously. So the data is transferred using "emit" into a signal / function. But from there, I just access the device object which works fine for all other data. Now, all threads of my application share the same memory map, don't they? And device as wenn as the rfPower4x1 are dynamically reserved, so they are on the heap? That's why I don't see a problem in there, am I right with my suggestion?

Then, maybe I can get some closer to a solution wondering would be the situation if I don't use dynamic memory but us the objects directly instead? Aren't they then placed on the stack? How do different threads then find where the object is, without getting confused by various heights that the stack can have?

Regards, Stephan

SGaist

Can you share your code ?

Where are you accessing device ? Where is it allocated ?

StephanWoebbeking

Sure, its only rather complex already and I don't really see how to strip it down as it involves communication with an external device...

The definition for the device pointer is in the mainwindow.h:

private:
...    wbstlDevice *device;
    QByteArray tmpBuffer, rfPower4x1;
    QString fl7TextBuffer;

The instantiation is in the constructor for the mainwindow.cpp:

MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow) {
...
    device  = new wbstlDevice( this );

I use dynamic instantiation to allow the device having access back to the window via the pointer.

Then wbstlDevice is defined like this:

#ifndef WBSTLDEVICE_H
#define WBSTLDEVICE_H

#include <QObject>
#include <QByteArray>
#include <QString>

class wbstlDevice {
public:
    wbstlDevice( QObject *parent = 0 );
    virtual ~wbstlDevice();
    void reset();
    bool convert2IdTo3Id( unsigned char devketId, unsigned char rfId );
    bool isInitialized();
    bool initDevice();
    bool supportsFpSync();
    bool supportsClockCorrection();
    bool usesTestTone();
    bool usesTestMode();
    bool needsTestMode4TransmissionTest();
    bool canUseTestTone();

    virtual void addRFPower4X1( QByteArray data );
    virtual unsigned int convertSvcCmdIdToCmdInt( unsigned int svcCmd );
    virtual unsigned int getChannelFreqMHz( unsigned int channel );
    virtual unsigned int rfPower4x1Length(); // returns length in indices! One index contains 6 bytes / 12 nibbles
    bool isRfPower4x1Valid();
    QString convertSvcCmdIdToCmdStr( unsigned int svcCmd );
    unsigned int convertCmdIdToSvcCmd( unsigned int rawCmd );
    unsigned int convertCmdStrToSvcCmd( QString cmdStr );
    QString getSWVersionStr();
    void setSWVersion( QByteArray data );
    char getAdaptivePower();

    bool deviceNameChanged, serialIDChanged, autoLockChanged, pairingChanged, identifyChanged, walktestChanged, debugScreenChanged;
    bool initialized, testMode, validEEVersion, needsDectModeCorrection;
    char deviceId, marketId, rfId, devketId, fpSync;
    char swVersion[ 3 ];
    QString errorString;
    int freqStart, freqStep, freqCount;
    wbstlDevice *currentDevice, *deviceSRX1G9, *deviceSRX2G4, *devicePRX1G9, *devicePTX1G9, *devicePTX2G4;
    QByteArray rfPower4x1;
};
#endif // WBSTLDEVICE_H

As I said for simplification I do access the rfPower4x1 field directly (public). The method "isRfPower4x1Valid" is defined like this:

bool wbstlDevice::isRfPower4x1Valid() {
    bool ret = true;
    int idx1, idx2, sum, expLength;

    expLength = ( currentDevice->rfPower4x1Length() * WbstlConst::RF_POWER_4X1_INDEX_LENGTH );
    if ( rfPower4x1.length() != expLength )
        ret = false;
    idx1 = 0;
    while ( idx1 < expLength ) {
        sum = 0;
        for ( idx2 = 0; idx2 < WbstlConst::RF_POWER_4X1_INDEX_LENGTH; idx1++, idx2++ )
            sum += rfPower4x1.at( idx1 );
        if ( ( sum == 0x00 ) || ( sum == 0xFF ) )
            ret = false;
    }

    return ret;
}

And in the mainwindow is did like this:

        device->rfPower4x1.clear();
        device->rfPower4x1.append( data );
        appendLog( ants::printHex( device->rfPower4x1 ) );
        appendLog( QString( "%1" ).arg( device->rfPower4x1.length() ) );
        if ( device->isRfPower4x1Valid() )
            appendLog( "RF power 4x1:          ok" );
        else
            appendLog( QString( "RF power 4x1 contains some errors: %1" ).arg( ants::printHex( data ) ) );

Even rfPower4x1 is statically instantiated, I get the SIGSEGV only when I clear the array... any more ideas?

Regards,
Stephan

jsulm

"I use dynamic instantiation to allow the device having access back to the window via the pointer" - no need for dynamic allocation. Do:

MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow), wbstlDevice( this )
{}

In general, Device should not know anything about MainWindow - else it is bad design. If you need to communicate from Device to MainWindow you should emit signals in Device which MainWindow connects to own slots. This way Device does not care about MainWindow implementation (if you change something in MainWindow you do not have to change Device).

StephanWoebbeking

@jsulm Ok, I am aware that there is some redesign suitable. Also with respect to the device and the sub-class structure. But does this helps us with regard to the segmentation fault? I was planning to do that in a refactoring session some time down the line, but if you think that it is essential for the function I would have to reschedule...?

Stephan

jsulm

You could try to change wbstlDevice to an instance variable instead of pointer and see whether is still crashes.

Gerd

The few lines of code you shown so far didn't seem to have any error.
As you where talking about asynchronus data filling this error may be thread-related.
How is the method in MainWindow called that deals with device ?

StephanWoebbeking

@jsulm I have made it an object member instead of a pointer now. Did the same to the "device" object which was a pointer before but which - I think - doesn't have much to do with it.

Anyway, both did not show any effect. I also added some initial data to the QByteArray in the constructor - this data is still there (the debugger shows it) when I want to add more data. Even, now I only add one more static byte - just to try it. Still I receive the segmentation fault...

No more ideas, anyone else?

Stephan

StephanWoebbeking

@Gerd Well, the object "device" is basically used everywhere in the mainwindow class as it holds some information used in a lot of cases. For the specific method I do call a slot using a signal, then its a method of the mainwindow and that has direct access to "device". As this holds the QByteArray I can access it without any (compiler) problems, but I get the segmentation fault...

Stephan

Gerd

As you are talking about multithreading did you try to use a queued connection when connecting the involved Signals/Slots?

StephanWoebbeking

Hi, me again...

I have run a quick test... removed the line of

device.rfPower4x1.append( 0x74 );

for

device.appendRfPower4x1( 0x74 );

Now, obviously I had to introduce this method like this:

void wbstlDevice::appendRfPower4x1(char data) {
    rfPower4x1.append( data );
}

The result is, that I still get a segmentation fault but this occurs actually a few lines further down - things that were working fine before??? I feels to me like there is some issue with thread safety, threads in general I am not completely aware off. Does that ring a bell for anyone?

Thanks,
Stephan