Segmentation fault SIGSEGV, what can it be?
-
@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
-
You could try to change wbstlDevice to an instance variable instead of pointer and see whether is still crashes.
-
@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
-
@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
-
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 -
Could it be a problem in general, that I use "device" as a member variable of the "mainwindow" after I have connected one method of "mainwindow" to another? Now I tried both, to use "device" as a member variable and as an argument that I have transferred via the emit call. So there is multithreading coming into place, is there anything behind I haven't considered yet?
Stephan
-
@Gerd Right, I still had this on my list to try it out... I have now changed the "connect" to this:
connect( this, SIGNAL( rcvProdTestFromCOM( QString, QByteArray ) ), this, SLOT( rcvProdTestFromCOMSlot( QString, QByteArray ) ), Qt::QueuedConnection );
From my perspective that's all I have to do to make it queued, right? Nothing else to change in the definitions for signals or slots?
Tried this out: Same effect, still get a segmentation fault... :-(
Can somebody confirm if there is any issue behind I may have overseen when using the SAME object in the code BEFORE calling EMIT and in the code of the SLOT?
Regards,
Stephan -
This post is deleted!