Segmentation fault SIGSEGV, what can it be?

[StephanWoebbeking]

Hi guys,
I have some trouble with my code giving me a segmentation fault. In general I have an idea where it may come from, but here I seem to be a blockhead...

The main area in a private method of my mainWindow class reads like this:

        device->rfPower4x1 = new QByteArray();
        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" );

device is a "normal" class I have created myself. rfPower4x1 is a simple pointer to a QByteArray, public to the device.
If I run through, the segmentation fault occurs in the method isRfPower4x1Valid() from the device:

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;
}

It occurs in line 6, where the length() of the rfPower4x1 field is requested. But why, I accessed the field in the code above, BEFORE isRfPower4x1Valid() was called, any the system didn't object...?

Now, to take that further, I remove the instantiation of the rfPower4x1 field. I reckon I can do that, because the constructor of device does it already:

wbstlDevice::wbstlDevice( QObject *parent ) {
...
    rfPower4x1 = new QByteArray();
}

If have checked with the debugger that constructor is called and finished BEFORE the code under question is executed, everything as I would expect.
If I now run through the code (without the ...new QByteArray() in it), I get the segmentation fault already in this line:

        device->rfPower4x1->clear();

I looks througth it now the second day and just don't see any problem, I just feel it must be very obvious. I have been thinking about multi-threading but this thougth didn't get me anywhere?

I have also been experimenting with the rfPower4x1 being the QByteArray directly and not a pointer, but I hit pretty much exactly the same issue. From the architectural point of view I have my preferences, but I would like to handle this issue first.

So maybe someone can point me into the correct direction? I am working with Qt Creator 3.1.1, based on Qt 5.2.1, May 2014, 32 bit.

Thanks a lot,
Stephan

[jsulm]

Run through the debugger and do step by step execution and check the pointers. Most probably one of them is either null or is pointing to nowhere.

Is where a reason why rfPower4x1 is a pointer?
And calling clear() on a fresh QByteArray does not make any sense - it is empty by default.

[StephanWoebbeking]

Hi jsulm,

Run through the debugger and do step by step execution and check the pointers. Most probably one of them is either null or is pointing to nowhere.

Exactly that is my problem! Within the device method isRfPower4x1Valid(), the device internal field rfPower4x1 is null and therefore I get the segmentation fault. When I don't do the first line initialization then I see and empty QByteArray but I get the segmentation fault on clear. In both cases: Why is this? Why is the pointer "not accessible" while I was using it just before, there is no thread change or something in the code. And why do I get the segementation fault, when I see an empty QByteArray?

Is where a reason why rfPower4x1 is a pointer?

As I wrote in the end, I was using it directly before but started to experiment with it...

And calling clear() on a fresh QByteArray does not make any sense - it is empty by default.

Yep, quite clear, but still it should work, shouldn't it? At least it does, so I am aware of it, but that's not really the issue. Once I can clear the SIGSEGV I will clean all this up...

Any more hints?

Regards,
Stephan

[Gerd]

Hi,
are you sure that your currentDevice Pointer points to device that was initiated before?

Regards
gerd

[StephanWoebbeking]

@Gerd Pretty much; all other data is correctly stored in that object. So there's a bunch of primitive data (ints, bools, chars, etc), these all work good, no problem there. Also, when I do "device->rfPower4x1 = new QByteArray();", the array is stored correctly, clear() and append() work. Only when I then access it via the device object, it fails and delivers SIGSEGV.

Stephan

[Gerd]

Hi,
looks like the pointer is changed anywhere.
From the given lines of code i assume that "rfPower4x1" is a public variable, so it may be changed from everywhere.
What you can do to find the error:

• search for "rfPower4x1" in the project and check every assignment to that
• make "rfPower4x1" privat to your class and implement some function for accessing the data, so the pointer self can only be changed from within the class
• use a data-breakpoint in the debugger

Regards
gerd

[SGaist]

Hi,

Out of curiosity, why are you instantiating a new QByteArray ? That's an unusual use of that class

[StephanWoebbeking]

Hi Gerd, I have searched through all access to rfPower4x1, there is no contradicting access to it at all. I only assign it in the constructor of the device, I do "clear" every now and then, so I could understand if its empty, but the instance should still exist?!? Especially, there is no assignment at all where a null pointer could be the result. So from the first access there should be a valid object behind... Also the device object is used extensively, so this can not have been destroyed yet from my point of view.

I have made the data public, because it's not that huge project overall. And this device object is bound quite closely to the mainwindow anyway. So I didn't see extensive need for data hiding, even I know from the pure architectural point of view it would be the right thing. But as the mainwindow would be able to access the data via methods anyway and the device itself doesn't really do much with the data but only stores it I didn't see much use from it...

Obviously I have used breakpoints a lot already, but it didn't get me anywhere. I didn't use a data-breakpoint yet, I have to check that out first I must admit...

Stephan

[StephanWoebbeking]

@SGaist said:

Out of curiosity, why are you instantiating a new QByteArray ? That's an unusual use of that class

I worked with the instance directly before, but I hit the same issue. And because I had no more ideas I changed over to a pointer. I think I will change it back, doesn't make it worse I hope. I will tell you if it gets me anywhere.

I must admit, still I have no bl***y idea, where the problem could be. This seems to be quite a standard way of doing things, I use the QByteArray a lot, I use objects in general, I don't really have much problem with either both of it. It's just this one single point where I just can't work out what the problem is... I suppose it's something really silly and its right afront my eyes, I just don't see it....

Stephan

[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 ?