Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Segmentation fault SIGSEGV, what can it be?
QtWS25 Last Chance

Segmentation fault SIGSEGV, what can it be?

Scheduled Pinned Locked Moved Unsolved General and Desktop
sigsegvsegmentationfaultmemorymanagement
34 Posts 6 Posters 32.5k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Offline
    S Offline
    StephanWoebbeking
    wrote on 21 Dec 2015, 09:50 last edited by
    #21

    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

    1 Reply Last reply
    0
    • J Offline
      J Offline
      jsulm
      Lifetime Qt Champion
      wrote on 21 Dec 2015, 11:09 last edited by
      #22

      "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).

      https://forum.qt.io/topic/113070/qt-code-of-conduct

      S 1 Reply Last reply 21 Dec 2015, 11:50
      0
      • J jsulm
        21 Dec 2015, 11:09

        "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).

        S Offline
        S Offline
        StephanWoebbeking
        wrote on 21 Dec 2015, 11:50 last edited by
        #23

        @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

        1 Reply Last reply
        0
        • J Offline
          J Offline
          jsulm
          Lifetime Qt Champion
          wrote on 21 Dec 2015, 12:33 last edited by
          #24

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

          https://forum.qt.io/topic/113070/qt-code-of-conduct

          S 1 Reply Last reply 6 Jan 2016, 11:58
          0
          • G Offline
            G Offline
            Gerd
            wrote on 21 Dec 2015, 13:21 last edited by
            #25

            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 ?

            1 Reply Last reply
            0
            • J jsulm
              21 Dec 2015, 12:33

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

              S Offline
              S Offline
              StephanWoebbeking
              wrote on 6 Jan 2016, 11:58 last edited by
              #26

              @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

              S 1 Reply Last reply 6 Jan 2016, 12:02
              0
              • S StephanWoebbeking
                6 Jan 2016, 11:58

                @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

                S Offline
                S Offline
                StephanWoebbeking
                wrote on 6 Jan 2016, 12:02 last edited by
                #27

                @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

                1 Reply Last reply
                0
                • G Offline
                  G Offline
                  Gerd
                  wrote on 6 Jan 2016, 13:06 last edited by
                  #28

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

                  1 Reply Last reply
                  0
                  • S Offline
                    S Offline
                    StephanWoebbeking
                    wrote on 6 Jan 2016, 13:37 last edited by
                    #29

                    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

                    1 Reply Last reply
                    0
                    • S Offline
                      S Offline
                      StephanWoebbeking
                      wrote on 6 Jan 2016, 16:53 last edited by
                      #30

                      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

                      1 Reply Last reply
                      0
                      • G Offline
                        G Offline
                        Gerd
                        wrote on 6 Jan 2016, 18:51 last edited by
                        #31

                        Look two posts above....

                        S 1 Reply Last reply 7 Jan 2016, 09:37
                        0
                        • G Gerd
                          6 Jan 2016, 18:51

                          Look two posts above....

                          S Offline
                          S Offline
                          StephanWoebbeking
                          wrote on 7 Jan 2016, 09:37 last edited by
                          #32

                          @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

                          kshegunovK 1 Reply Last reply 7 Jan 2016, 11:28
                          0
                          • S StephanWoebbeking
                            7 Jan 2016, 09:37

                            @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

                            kshegunovK Offline
                            kshegunovK Offline
                            kshegunov
                            Moderators
                            wrote on 7 Jan 2016, 11:28 last edited by kshegunov 1 Jul 2016, 11:32
                            #33
                            This post is deleted!
                            1 Reply Last reply
                            0
                            • I Offline
                              I Offline
                              IvanC
                              wrote on 8 Nov 2017, 07:59 last edited by
                              #34

                              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.

                              1 Reply Last reply
                              0

                              • Login

                              • Login or register to search.
                              • First post
                                Last post
                              0
                              • Categories
                              • Recent
                              • Tags
                              • Popular
                              • Users
                              • Groups
                              • Search
                              • Get Qt Extensions
                              • Unsolved