Segmentation fault SIGSEGV, what can it be?
-
wrote on 21 Dec 2015, 13:21 last edited by
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 ? -
You could try to change wbstlDevice to an instance variable instead of pointer and see whether is still crashes.
wrote on 6 Jan 2016, 11:58 last edited by@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
-
@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
wrote on 6 Jan 2016, 12:02 last edited by@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
-
wrote on 6 Jan 2016, 13:06 last edited by
As you are talking about multithreading did you try to use a queued connection when connecting the involved Signals/Slots?
-
wrote on 6 Jan 2016, 13:37 last edited by
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 -
wrote on 6 Jan 2016, 16:53 last edited by
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
-
wrote on 6 Jan 2016, 18:51 last edited by
Look two posts above....
-
wrote on 7 Jan 2016, 09:37 last edited by
@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 -
@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,
StephanModeratorswrote on 7 Jan 2016, 11:28 last edited by kshegunov 1 Jul 2016, 11:32This post is deleted! -
wrote on 8 Nov 2017, 07:59 last edited by
Hi, i was experiencing the same strange thing... i was using Qt headers and non Qt headers, and placing before the Qt headers seemed to have solved the problem.