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. Segfault when calling QWidget::show (on Debian 9)
Forum Updated to NodeBB v4.3 + New Features

Segfault when calling QWidget::show (on Debian 9)

Scheduled Pinned Locked Moved Solved General and Desktop
49 Posts 6 Posters 6.8k Views 3 Watching
  • 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.
  • B Bart_Vandewoestyne

    OK, I think we're getting there... In ICBlackBoxBase::mfInitialize we call the ICBlackBoxBaseApplication constructor which calls the QApplication constructor with certain argc and argv arguments:

    ICBlackBoxBaseApplication::ICBlackBoxBaseApplication(int &argc, char** argv, ICBlackBoxBase* apApp)
    : QApplication(argc,argv), mpApp(apApp)
    {
    }
    

    Now let's see what argc and argv we are passing there. I've set a breakpoint right before the location where we call this constructor, and this is the call stack:

    (gdb) bt
    #0  ICBlackBoxBase::mfInitialize (this=0x7fffffffe0e0, argc=2, argv=0x5555565cd3d0, errormsg=...) at ICBlackBoxBase.cpp:101
    #1  0x0000555555c0101d in ICService::mfExec(int, char**, QString&, bool) ()
    #2  0x0000555555bfd86e in ICService::mfParseArguments(int, char**, bool) ()
    #3  0x000055555594db13 in BSPPolarisSlave::mfParseArguments (this=0x7fffffffe0e0, argc=2, argv=0x7fffffffe258) at BSPPolarisSlave.cpp:654
    #4  0x000055555592a3bd in main (argc=1, argv=0x7fffffffe258) at BSPPolarisSlaveMain.cpp:71
    

    As you can see, in main we have that argc is 1, but in ICBlackBoxBase::mfInitialize (the function from which we call the ICBlackBoxBaseApplication constructor, and thus also the QApplication constructor) we have that argc is 2 (since an extra -e argument was added). Now let's look at argv in both main and ICBlackBoxBase::mfInitialize. In main we have:

    (gdb) f 4
    #4  0x000055555592a3bd in main (argc=1, argv=0x7fffffffe258) at BSPPolarisSlaveMain.cpp:71
    71		return (polarisSlave.mfParseArguments(argc, argv));	
    (gdb) p argc
    $12 = 1
    (gdb) p argv[0]
    $13 = 0x7fffffffe53a "/home/user/SVN/PolarisRel/Apps/PolarisSlave"
    (gdb) p argv[argc]
    $14 = 0x0
    

    but in ICBlackBoxBase::mfInitialize we have:

    (gdb) f 0
    #0  ICBlackBoxBase::mfInitialize (this=0x7fffffffe0e0, argc=2, argv=0x5555565cd3d0, errormsg=...) at ICBlackBoxBase.cpp:101
    101	{
    (gdb) p argc
    $15 = 2
    (gdb) p argv[0]
    $16 = 0x5555565cf830 "/home/user/SVN/PolarisRel/Apps/PolarisSlave"
    (gdb) p argv[1]
    $17 = 0x5555565cf940 "-e"
    (gdb) p argv[argc]
    $18 = 0x20 <error: Cannot access memory at address 0x20>
    

    so there argv[argc] is not null! And now I have to find out why :-)

    JonBJ Offline
    JonBJ Offline
    JonB
    wrote on last edited by JonB
    #37

    @Bart_Vandewoestyne said in Segfault when calling QWidget::show (on Debian 9):

    ICBlackBoxBaseApplication::ICBlackBoxBaseApplication(int &argc, char** argv, ICBlackBoxBase* apApp)
    : QApplication(argc,argv), mpApp(apApp)
    {
    }
    

    I have an alternative theory. Work with me on this one, please!

    I believe the BSPPolarisSlave & ICService classes are your own(?). This ICBlackBoxBaseApplication constructor calls QApplication(argc,argv) with argc, and especially argv, *with the values they have on entry to the constructor. However (I believe you are saying) something it then does alters argc, and especially argv, to add further arguments, right? Note in your traceback how argv has a different (pointer) value from BSPPolarisSlave::mfParseArguments() down to ICBlackBoxBase::mfInitialize() --- it has been changed.

    Now, I am unclear whether the original argv, with its strings, is being used from the original QApplication(argc,argv), and just possibly the value/strings array is no longer valid. But it may be what is used the very first time QWidget::show() is called (to do some X initialisations from any (potential) X-type command-line arguments passed to your Qt app. Remember that https://doc.qt.io/qt-5/qcoreapplication.html#QCoreApplication says

    Warning: The data referred to by argc and argv must stay valid for the entire lifetime of the QCoreApplication object. In addition, argc must be greater than zero and argv must contain at least one valid character string.

    I think you should find that QWidget::show() which is in BSPPolarisSlave::mfRun(). On the line above it do something about printing out Qt's idea of the command line arguments which were used during the earlier QApplication(argc,argv). I believe static QStringList QCoreApplication::arguments() accesses these. So qDebug() those before QWidget::show(), do they look good or garbled?

    Finally, the question is why/what are these classes altering argc/argvfor, apparently to add additional arguments? If these new arguments are intended to be seen by Qt then it looks like you should not be callingQApplication(argc,argv)` until after they have been modified to hold the new command line?

    B 1 Reply Last reply
    0
    • B Offline
      B Offline
      Bart_Vandewoestyne
      wrote on last edited by
      #38

      I have also found the following text on https://doc.qt.io/archives/qt-4.8/qapplication.html#details

      "Since the QApplication object does so much initialization, it must be created before any other objects related to the user interface are created. QApplication also deals with common command line arguments. Hence, it is usually a good idea to create it before any interpretation or modification of argv is done in the application itself."

      It worries me... I don' think we actually modify argv (but we do modify argc)... but we do create a newArgv that has one more command line argument and that newArgv together with the modified argc is what gets passed to QApplication later on...

      So in summary, I think this is what we do:

      1. Start from main with argc and argv.
      2. increment argc by one and create newArgv from argv (newArgv has one extra -e command line argument).
      3. Call the QApplication constructor with the incremented argc and newArgv...
      JonBJ 1 Reply Last reply
      0
      • B Bart_Vandewoestyne

        I have also found the following text on https://doc.qt.io/archives/qt-4.8/qapplication.html#details

        "Since the QApplication object does so much initialization, it must be created before any other objects related to the user interface are created. QApplication also deals with common command line arguments. Hence, it is usually a good idea to create it before any interpretation or modification of argv is done in the application itself."

        It worries me... I don' think we actually modify argv (but we do modify argc)... but we do create a newArgv that has one more command line argument and that newArgv together with the modified argc is what gets passed to QApplication later on...

        So in summary, I think this is what we do:

        1. Start from main with argc and argv.
        2. increment argc by one and create newArgv from argv (newArgv has one extra -e command line argument).
        3. Call the QApplication constructor with the incremented argc and newArgv...
        JonBJ Offline
        JonBJ Offline
        JonB
        wrote on last edited by
        #39

        @Bart_Vandewoestyne
        I know this. I suggested what you need to do, to the QWidget::show() in BSPPolarisSlave::mfRun()....

        B 1 Reply Last reply
        0
        • JonBJ JonB

          @Bart_Vandewoestyne
          I know this. I suggested what you need to do, to the QWidget::show() in BSPPolarisSlave::mfRun()....

          B Offline
          B Offline
          Bart_Vandewoestyne
          wrote on last edited by
          #40

          @JonB said in Segfault when calling QWidget::show (on Debian 9):

          @Bart_Vandewoestyne
          I know this. I suggested what you need to do, to the QWidget::show() in BSPPolarisSlave::mfRun()....

          Yes, thanks for that suggestion. I'll look into it. I guess we were both typing our replies at the same time, but you were the first to press the 'Submit' button :-) Stay tuned for more! :-)

          JonBJ 1 Reply Last reply
          0
          • B Bart_Vandewoestyne

            @JonB said in Segfault when calling QWidget::show (on Debian 9):

            @Bart_Vandewoestyne
            I know this. I suggested what you need to do, to the QWidget::show() in BSPPolarisSlave::mfRun()....

            Yes, thanks for that suggestion. I'll look into it. I guess we were both typing our replies at the same time, but you were the first to press the 'Submit' button :-) Stay tuned for more! :-)

            JonBJ Offline
            JonBJ Offline
            JonB
            wrote on last edited by JonB
            #41

            @Bart_Vandewoestyne
            Hold on.

            First there is a logic fault in new code. Although it may not matter to your error right now, because you are still inside ICService::mfParseArguments(argc, newArgs.data()), your newArgs (local) variable does not respect

            The data referred to by argc and argv must stay valid for the entire lifetime of the QCoreApplication object

            At least try making newArgs static.

            You still have not said "who" is supposed to "see" these extra arguments --- QCoreApplication or not?

            Also, who uses the -e you append, and are you sure what uses that does not expect a further argument to follow the -e? [EDIT Oh, I see you insert the -e, not append it.]

            1 Reply Last reply
            0
            • JonBJ JonB

              @Bart_Vandewoestyne said in Segfault when calling QWidget::show (on Debian 9):

              ICBlackBoxBaseApplication::ICBlackBoxBaseApplication(int &argc, char** argv, ICBlackBoxBase* apApp)
              : QApplication(argc,argv), mpApp(apApp)
              {
              }
              

              I have an alternative theory. Work with me on this one, please!

              I believe the BSPPolarisSlave & ICService classes are your own(?). This ICBlackBoxBaseApplication constructor calls QApplication(argc,argv) with argc, and especially argv, *with the values they have on entry to the constructor. However (I believe you are saying) something it then does alters argc, and especially argv, to add further arguments, right? Note in your traceback how argv has a different (pointer) value from BSPPolarisSlave::mfParseArguments() down to ICBlackBoxBase::mfInitialize() --- it has been changed.

              Now, I am unclear whether the original argv, with its strings, is being used from the original QApplication(argc,argv), and just possibly the value/strings array is no longer valid. But it may be what is used the very first time QWidget::show() is called (to do some X initialisations from any (potential) X-type command-line arguments passed to your Qt app. Remember that https://doc.qt.io/qt-5/qcoreapplication.html#QCoreApplication says

              Warning: The data referred to by argc and argv must stay valid for the entire lifetime of the QCoreApplication object. In addition, argc must be greater than zero and argv must contain at least one valid character string.

              I think you should find that QWidget::show() which is in BSPPolarisSlave::mfRun(). On the line above it do something about printing out Qt's idea of the command line arguments which were used during the earlier QApplication(argc,argv). I believe static QStringList QCoreApplication::arguments() accesses these. So qDebug() those before QWidget::show(), do they look good or garbled?

              Finally, the question is why/what are these classes altering argc/argvfor, apparently to add additional arguments? If these new arguments are intended to be seen by Qt then it looks like you should not be callingQApplication(argc,argv)` until after they have been modified to hold the new command line?

              B Offline
              B Offline
              Bart_Vandewoestyne
              wrote on last edited by
              #42

              @JonB said in Segfault when calling QWidget::show (on Debian 9):

              I believe the BSPPolarisSlave & ICService classes are your own(?).

              For the record: yes. I even think the ICService class is based on an older version of QtService from https://skycoder42.github.io/QtService/.

              This ICBlackBoxBaseApplication constructor calls QApplication(argc,argv) with argc, and especially argv, *with the values they have on entry to the constructor. However (I believe you are saying) something it then does alters argc, and especially argv, to add further arguments, right?

              I think it's the other way around: we create a newArgv that has one extra -e parameter and we also increment argc, and those are eventually passed to QApplication.

              Note in your traceback how argv has a different (pointer) value from BSPPolarisSlave::mfParseArguments() down to ICBlackBoxBase::mfInitialize() --- it has been changed.

              OK. This indeed sounds not good... I will look into that.

              [...]
              I think you should find that QWidget::show() which is in BSPPolarisSlave::mfRun(). On the line above it do something about printing out Qt's idea of the command line arguments which were used during the earlier QApplication(argc,argv). I believe static QStringList QCoreApplication::arguments() accesses these. So qDebug() those before QWidget::show(), do they look good or garbled?

              I've changed

              mpMainWindow->show();
              

              into

              QApplication::arguments();
              mpMainWindow->show();
              

              and when I run the program in gdb, it now no longer crashes at the call to show(), but rather at the call to QApplication::arguments(), again pointing in the direction that clearly something is wrong with this argc, argv and newArgvs code...

              Finally, the question is why/what are these classes altering argc/argvfor, apparently to add additional arguments? If these new arguments are intended to be seen by Qt then it looks like you should not be callingQApplication(argc,argv)` until after they have been modified to hold the new command line?

              This is the code that does the modification:

              	//As PolarisSlave is derived from ICService we must start with -e argument to run
              	//PolarisSlave as a regular program and not as a service.
              	char** newArgvs;
              	newArgvs = new char*[argc+1];
              	for(i = 0; i < argc + 1; i++)
              	{
              		newArgvs[i] = new char[256];
              	}
              
              	strcpy(newArgvs[0], argv[0]);
              
              	if (!showHelp)
              	{
              		strcpy(newArgvs[1], "-e");		
              		for(i = 1; i < argc; i++)
              		{
              			strcpy(newArgvs[i+1], argv[i]);
              		}
              		argc++;
              	}
              	else
              	{
              		strcpy(newArgvs[1], "-h");
              	}
              
                      return ICService::mfParseArguments(argc, newArgvs, false);
              

              Note that we first do the argc/argv/newArgvs stuff, and then we call the function

              return ICService::mfParseArguments(argc, newArgvs, false);
              

              which passes these arguments on to other functions and eventually calls the QApplication constructor with these modified arguments.

              Also, reading the first comment, I would say that that -e argument is added because we don't want to start the program as a service (remember our ICService class is probably based on QtService, and using -e seems to avoid that we run it as a service).

              JonBJ Christian EhrlicherC 2 Replies Last reply
              0
              • B Bart_Vandewoestyne

                @JonB said in Segfault when calling QWidget::show (on Debian 9):

                I believe the BSPPolarisSlave & ICService classes are your own(?).

                For the record: yes. I even think the ICService class is based on an older version of QtService from https://skycoder42.github.io/QtService/.

                This ICBlackBoxBaseApplication constructor calls QApplication(argc,argv) with argc, and especially argv, *with the values they have on entry to the constructor. However (I believe you are saying) something it then does alters argc, and especially argv, to add further arguments, right?

                I think it's the other way around: we create a newArgv that has one extra -e parameter and we also increment argc, and those are eventually passed to QApplication.

                Note in your traceback how argv has a different (pointer) value from BSPPolarisSlave::mfParseArguments() down to ICBlackBoxBase::mfInitialize() --- it has been changed.

                OK. This indeed sounds not good... I will look into that.

                [...]
                I think you should find that QWidget::show() which is in BSPPolarisSlave::mfRun(). On the line above it do something about printing out Qt's idea of the command line arguments which were used during the earlier QApplication(argc,argv). I believe static QStringList QCoreApplication::arguments() accesses these. So qDebug() those before QWidget::show(), do they look good or garbled?

                I've changed

                mpMainWindow->show();
                

                into

                QApplication::arguments();
                mpMainWindow->show();
                

                and when I run the program in gdb, it now no longer crashes at the call to show(), but rather at the call to QApplication::arguments(), again pointing in the direction that clearly something is wrong with this argc, argv and newArgvs code...

                Finally, the question is why/what are these classes altering argc/argvfor, apparently to add additional arguments? If these new arguments are intended to be seen by Qt then it looks like you should not be callingQApplication(argc,argv)` until after they have been modified to hold the new command line?

                This is the code that does the modification:

                	//As PolarisSlave is derived from ICService we must start with -e argument to run
                	//PolarisSlave as a regular program and not as a service.
                	char** newArgvs;
                	newArgvs = new char*[argc+1];
                	for(i = 0; i < argc + 1; i++)
                	{
                		newArgvs[i] = new char[256];
                	}
                
                	strcpy(newArgvs[0], argv[0]);
                
                	if (!showHelp)
                	{
                		strcpy(newArgvs[1], "-e");		
                		for(i = 1; i < argc; i++)
                		{
                			strcpy(newArgvs[i+1], argv[i]);
                		}
                		argc++;
                	}
                	else
                	{
                		strcpy(newArgvs[1], "-h");
                	}
                
                        return ICService::mfParseArguments(argc, newArgvs, false);
                

                Note that we first do the argc/argv/newArgvs stuff, and then we call the function

                return ICService::mfParseArguments(argc, newArgvs, false);
                

                which passes these arguments on to other functions and eventually calls the QApplication constructor with these modified arguments.

                Also, reading the first comment, I would say that that -e argument is added because we don't want to start the program as a service (remember our ICService class is probably based on QtService, and using -e seems to avoid that we run it as a service).

                JonBJ Offline
                JonBJ Offline
                JonB
                wrote on last edited by JonB
                #43

                @Bart_Vandewoestyne said in Segfault when calling QWidget::show (on Debian 9):

                QApplication::arguments();

                I said to try:

                qDebug() << QApplication::arguments();
                

                though of course it will crash.

                Your code looks dodgy to me, at least in the showHelp case, which probably doesn't arise in your current example. I'm not going to type up the potential issues you might encounter, use a debugger if you want to step through. I don't know how that relates to the issue of the QApplication arguments anyway. I don't know why you insert a -e in this code when you previously showed newArgs.push_back(const_cast<char*>("-e")); elsewhere.

                Basically I am finding it too difficult to follow your code, and I'm not sure if you are changing stuff. In any case this should be a debugging exercise now. I can see that the first QWidget call needs QApplication::arguments() to be correct, and I think that is not, so follow how that goes from valid to inavlid through your sequence of calls/changes.

                B 2 Replies Last reply
                0
                • JonBJ JonB

                  @Bart_Vandewoestyne said in Segfault when calling QWidget::show (on Debian 9):

                  QApplication::arguments();

                  I said to try:

                  qDebug() << QApplication::arguments();
                  

                  though of course it will crash.

                  Your code looks dodgy to me, at least in the showHelp case, which probably doesn't arise in your current example. I'm not going to type up the potential issues you might encounter, use a debugger if you want to step through. I don't know how that relates to the issue of the QApplication arguments anyway. I don't know why you insert a -e in this code when you previously showed newArgs.push_back(const_cast<char*>("-e")); elsewhere.

                  Basically I am finding it too difficult to follow your code, and I'm not sure if you are changing stuff. In any case this should be a debugging exercise now. I can see that the first QWidget call needs QApplication::arguments() to be correct, and I think that is not, so follow how that goes from valid to inavlid through your sequence of calls/changes.

                  B Offline
                  B Offline
                  Bart_Vandewoestyne
                  wrote on last edited by
                  #44

                  @JonB said in Segfault when calling QWidget::show (on Debian 9):

                  I said to try:

                  qDebug() << QApplication::arguments();
                  

                  I tried that, but I didn't get any output except for a segmentation fault. And that looked rather reasonable to me because I assume QApplication::arguments() gets called before operator<<, not? And if QApplication::arguments() segfaults, we won't see any further output...

                  1 Reply Last reply
                  0
                  • JonBJ JonB

                    @Bart_Vandewoestyne said in Segfault when calling QWidget::show (on Debian 9):

                    QApplication::arguments();

                    I said to try:

                    qDebug() << QApplication::arguments();
                    

                    though of course it will crash.

                    Your code looks dodgy to me, at least in the showHelp case, which probably doesn't arise in your current example. I'm not going to type up the potential issues you might encounter, use a debugger if you want to step through. I don't know how that relates to the issue of the QApplication arguments anyway. I don't know why you insert a -e in this code when you previously showed newArgs.push_back(const_cast<char*>("-e")); elsewhere.

                    Basically I am finding it too difficult to follow your code, and I'm not sure if you are changing stuff. In any case this should be a debugging exercise now. I can see that the first QWidget call needs QApplication::arguments() to be correct, and I think that is not, so follow how that goes from valid to inavlid through your sequence of calls/changes.

                    B Offline
                    B Offline
                    Bart_Vandewoestyne
                    wrote on last edited by
                    #45

                    @JonB said in Segfault when calling QWidget::show (on Debian 9):

                    [...]
                    Basically I am finding it too difficult to follow your code, and I'm not sure if you are changing stuff. In any case this should be a debugging exercise now. I can see that the first QWidget call needs QApplication::arguments() to be correct, and I think that is not, so follow how that goes from valid to inavlid through your sequence of calls/changes.

                    No problem. Thanks to you (and the others in this thread) for your help! I now have a clearer idea of where the problem is. It looks like it has indeed something to do with that modification of argc and argv. I'm used to debugging with the Visual Studio debugger, but this one has to be tackled in Linux, so I'll probably have to improve my gdb skills a bit... ;-)

                    1 Reply Last reply
                    0
                    • B Offline
                      B Offline
                      Bart_Vandewoestyne
                      wrote on last edited by
                      #46

                      For those that are still following this thread: there is again a little bit of progress. Since the call stack at the moment of the crash was

                      (gdb) bt
                      #0  strlen () at ../sysdeps/x86_64/strlen.S:106
                      #1  0x00007ffff3e101ed in XSetCommand () from /usr/lib/x86_64-linux-gnu/libX11.so.6
                      #2  0x00007ffff3e147f0 in XSetWMProperties () from /usr/lib/x86_64-linux-gnu/libX11.so.6
                      #3  0x00007ffff659007d in QWidgetPrivate::create_sys(unsigned long, bool, bool) () from /home/user/SVN/PolarisRel/ThirdParty/Qt/qt-install/lib/libQtGui.so.4
                      #4  0x00007ffff6548769 in QWidget::create(unsigned long, bool, bool) () from /home/user/SVN/PolarisRel/ThirdParty/Qt/qt-install/lib/libQtGui.so.4
                      #5  0x00007ffff6550697 in QWidget::setVisible(bool) () from /home/user/SVN/PolarisRel/ThirdParty/Qt/qt-install/lib/libQtGui.so.4
                      #6  0x000055555594a1fd in QWidget::show (this=<optimized out>) at ../../ThirdParty/Qt/qt-install/include/QtGui/qwidget.h:497
                      #7  BSPPolarisSlave::mfRun (this=0x7fffffffe0e0, argc=<optimized out>, argv=<optimized out>, errormsg=...) at BSPPolarisSlave.cpp:443
                      #8  0x0000555555c010da in ICService::mfExec(int, char**, QString&, bool) ()
                      #9  0x0000555555bfd90e in ICService::mfParseArguments(int, char**, bool) ()
                      #10 0x000055555594dbb3 in BSPPolarisSlave::mfParseArguments (this=0x7fffffffe0e0, argc=2, argv=0x7fffffffe258) at BSPPolarisSlave.cpp:659
                      #11 0x000055555592a3ad in main (argc=1, argv=0x7fffffffe258) at BSPPolarisSlaveMain.cpp:71
                      

                      and @JonB pointed me to the implementation of QWidgetPrivate::create_sys in src/gui/kernel/qwidget_x11.cpp (Qt 4.8.7), I wanted to see what the values of argc and argv were inside that create_sys function. Unfortunately, my Qt 4.8.7 build has no debug info, and I didn't find a way to create a Qt 4.8.7 build with debug info, so I added the following code right before the call to XSetWMProperties:

                              qDebug() << "Test by Bart";
                              qDebug() << "qApp->d_func()->argc == " << qApp->d_func()->argc;
                              for (int i = 0; i < qApp->d_func()->argc; ++i)
                              {
                                  qDebug() << "qApp->d_func()->argv[" << i << "] == " << qApp->d_func()->argv[i];
                              }
                      

                      and the output from within gdb is

                      (gdb) r
                      Starting program: /home/user/SVN/PolarisRel/Apps/PolarisSlave 
                      [Thread debugging using libthread_db enabled]
                      Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
                      Test by Bart 
                      qApp->d_func()->argc ==  32767 
                      qApp->d_func()->argv[ 0 ] ==  /home/user/SVN/PolarisRel/Apps/PolarisSlave 
                      qApp->d_func()->argv[ 1 ] ==  -e 
                      qApp->d_func()->argv[ 2 ] ==   
                      
                      Program received signal SIGSEGV, Segmentation fault.
                      0x00007ffff5bb5abb in QString::fromLatin1_helper(char const*, int) ()
                         from /home/user/SVN/PolarisRel/ThirdParty/Qt/qt-install/lib/libQtCore.so.4
                      (gdb)
                      

                      so it looks like it's the value of argc (32767 !!!!!) that is screwed up for some reason. I will now try to figure out where that happens.

                      1 Reply Last reply
                      0
                      • B Bart_Vandewoestyne

                        @JonB said in Segfault when calling QWidget::show (on Debian 9):

                        I believe the BSPPolarisSlave & ICService classes are your own(?).

                        For the record: yes. I even think the ICService class is based on an older version of QtService from https://skycoder42.github.io/QtService/.

                        This ICBlackBoxBaseApplication constructor calls QApplication(argc,argv) with argc, and especially argv, *with the values they have on entry to the constructor. However (I believe you are saying) something it then does alters argc, and especially argv, to add further arguments, right?

                        I think it's the other way around: we create a newArgv that has one extra -e parameter and we also increment argc, and those are eventually passed to QApplication.

                        Note in your traceback how argv has a different (pointer) value from BSPPolarisSlave::mfParseArguments() down to ICBlackBoxBase::mfInitialize() --- it has been changed.

                        OK. This indeed sounds not good... I will look into that.

                        [...]
                        I think you should find that QWidget::show() which is in BSPPolarisSlave::mfRun(). On the line above it do something about printing out Qt's idea of the command line arguments which were used during the earlier QApplication(argc,argv). I believe static QStringList QCoreApplication::arguments() accesses these. So qDebug() those before QWidget::show(), do they look good or garbled?

                        I've changed

                        mpMainWindow->show();
                        

                        into

                        QApplication::arguments();
                        mpMainWindow->show();
                        

                        and when I run the program in gdb, it now no longer crashes at the call to show(), but rather at the call to QApplication::arguments(), again pointing in the direction that clearly something is wrong with this argc, argv and newArgvs code...

                        Finally, the question is why/what are these classes altering argc/argvfor, apparently to add additional arguments? If these new arguments are intended to be seen by Qt then it looks like you should not be callingQApplication(argc,argv)` until after they have been modified to hold the new command line?

                        This is the code that does the modification:

                        	//As PolarisSlave is derived from ICService we must start with -e argument to run
                        	//PolarisSlave as a regular program and not as a service.
                        	char** newArgvs;
                        	newArgvs = new char*[argc+1];
                        	for(i = 0; i < argc + 1; i++)
                        	{
                        		newArgvs[i] = new char[256];
                        	}
                        
                        	strcpy(newArgvs[0], argv[0]);
                        
                        	if (!showHelp)
                        	{
                        		strcpy(newArgvs[1], "-e");		
                        		for(i = 1; i < argc; i++)
                        		{
                        			strcpy(newArgvs[i+1], argv[i]);
                        		}
                        		argc++;
                        	}
                        	else
                        	{
                        		strcpy(newArgvs[1], "-h");
                        	}
                        
                                return ICService::mfParseArguments(argc, newArgvs, false);
                        

                        Note that we first do the argc/argv/newArgvs stuff, and then we call the function

                        return ICService::mfParseArguments(argc, newArgvs, false);
                        

                        which passes these arguments on to other functions and eventually calls the QApplication constructor with these modified arguments.

                        Also, reading the first comment, I would say that that -e argument is added because we don't want to start the program as a service (remember our ICService class is probably based on QtService, and using -e seems to avoid that we run it as a service).

                        Christian EhrlicherC Offline
                        Christian EhrlicherC Offline
                        Christian Ehrlicher
                        Lifetime Qt Champion
                        wrote on last edited by Christian Ehrlicher
                        #47

                        @Bart_Vandewoestyne said in Segfault when calling QWidget::show (on Debian 9):

                        ICService::mfParseArguments(argc, newArgvs, false);

                        so is argc a local variable? If so then you have a dangling reference because Q(Core)Application takes a reference of argc and the documentation clearly states: Warning: The data referred to by argc and argv must stay valid for the entire lifetime of the QCoreApplication object. In addition, argc must be greater than zero and argv must contain at least one valid character string.

                        Already told you this 13 days ago btw.

                        Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
                        Visit the Qt Academy at https://academy.qt.io/catalog

                        B 1 Reply Last reply
                        1
                        • M Offline
                          M Offline
                          mchinand
                          wrote on last edited by
                          #48

                          If you have the source to ICService why are you setting whatever you're setting with the '-e' you're adding via argc/argv? I could possibly see doing it this way if you were setting a standard XWindows application argument (e.g., -geometry, -display, etc.) which I don't think '-e' is.

                          1 Reply Last reply
                          0
                          • Christian EhrlicherC Christian Ehrlicher

                            @Bart_Vandewoestyne said in Segfault when calling QWidget::show (on Debian 9):

                            ICService::mfParseArguments(argc, newArgvs, false);

                            so is argc a local variable? If so then you have a dangling reference because Q(Core)Application takes a reference of argc and the documentation clearly states: Warning: The data referred to by argc and argv must stay valid for the entire lifetime of the QCoreApplication object. In addition, argc must be greater than zero and argv must contain at least one valid character string.

                            Already told you this 13 days ago btw.

                            B Offline
                            B Offline
                            Bart_Vandewoestyne
                            wrote on last edited by
                            #49

                            @Christian-Ehrlicher said in Segfault when calling QWidget::show (on Debian 9):

                            so is argc a local variable? If so then you have a dangling reference because Q(Core)Application takes a reference of argc and the documentation clearly states: Warning: The data referred to by argc and argv must stay valid for the entire lifetime of the QCoreApplication object. In addition, argc must be greater than zero and argv must contain at least one valid character string.

                            Already told you this 13 days ago btw.

                            Finally! Yesterday the issue got fixed! The problem was indeed what @Christian-Ehrlicher hinted at (for which thanks!):

                            We have an mfInitialize function in which we create an object of type ICBlackBoxBaseApplication which subclasses QApplication and also takes argc by int& instead of by int.

                            bool ICBlackBoxBase::mfInitialize(int argc, char **argv, QString& errormsg)
                            {
                                   .... some stuff ...
                            
                            	mpApplication = new ICBlackBoxBaseApplication(argc, argv, this);
                            
                            	... other stuff ...
                            }
                            

                            and indeed, for as far as I understand this bug, once the mfInitialize function has returned, the ICBlackBoxBaseApplication thus has a dangling reference to the (meanwhile disappeared) argc variable, which was probably causing the segfault.

                            Passing argc by reference instead of by value

                            bool ICBlackBoxBase::mfInitialize(int& argc, char **argv, QString& errormsg)
                            

                            solved the problem.

                            Again many thanks to all in this thread who helped me think about this issue and work towards a solution. Especially @Christian-Ehrlicher (although I had the impression he was sometimes annoyed by my questions ;-) Note also that it took me more than 13 days to solve this, because there was Christmas holidays in between ;-)

                            1 Reply Last reply
                            2

                            • Login

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