3

I am developing a Qt 5.x application whose main function is more or less like that (simplified):

int main(int argc, char *argv[])
{
   QApplication app(arg, argv);

   QCommandLineParser cmdLineParser;
   cmdLineParser.addHelpOption();
   cmdLineParser.addVersionOption();

   cmdLineParser.process(app);

   /// *** SOME INITIALIZATION STUFF *** ///

   app.exec();
}

I am experiencing some problems when I invoke the execution of application specifying the --version (or --help) option on command line: the application outputs the version (or the help) and then sometimes terminates with a segmentation fault...

I think it is due to the fact that when QCommandLineParser detects a built-in option on command line (--version or --help) simply calls QApplication's exit() for terminating the execution and this interferes with my own *** SOME INITIALIZATION STUFF *** (basically some other threads are started and maybe a prematurely call on exit() causes some problems)...

However, my question is: is it possible to make Qt avoid to go further in my *** SOME INITIALIZATION STUFF *** if a built-in option is detected on command line? In other words, is there a method to be called for knowing that a built-in option has been detected by the command line parser? Otherwise: is there a method for knowing that exit() has been called on application, and hence the application is terminating? If so, it would suffice to enclose my *** SOME INITIALIZATION STUFF *** in a if condition argumenting on that method and it would be fine...

Thanks for the support.


>> EDIT <<

I've done some further investigations... the behavior seems not be dependent on my own *** SOME INITIALIZATION STUFF ***... in fact even a "minimal, complete and verifiable example" as the following one sometimes terminates the execution with segmentation fault when the executable is triggered with --version on the command line:

#include <QApplication>
#include <QCommandLineParser>

int main(int argc, char *argv[])
{
    // Instantiate the application
    QApplication app(argc, argv);
    app.setApplicationVersion("1.0.0");

    // Prepare for parsing the command line
    QCommandLineParser cmdLineParser;
    cmdLineParser.setApplicationDescription("Test application");

    // Add support for command line standard options (help & version)
    cmdLineParser.addHelpOption();
    cmdLineParser.addVersionOption();

    // Perform actual parsing of command line
    cmdLineParser.process(app);

    // Let the application run
    return app.exec();
}

Just to clarify, I am using Qt 5.3.2 on an ARM device running Linux OS.

Morix Dev
  • 2,700
  • 1
  • 28
  • 49
  • 1
    As I understand it, if the user is using the help or version options then `cmdLineParser.process(&app)` should *not even return!* So if you have problems they are in the code you do not show us. Please try to create a [Minimal, Complete, and Verifiable Example](http://stackoverflow.com/help/mcve) and show us, as well as telling us *what* options are used to make the crash happens. And of course run in a debugger to catch the crash and locate where it happens in *your* code. – Some programmer dude Mar 09 '17 at 11:05
  • Would `QCommandLineParser::parse()` be useful ? http://doc.qt.io/qt-5/qcommandlineparser.html#parse – Benjamin T Mar 09 '17 at 11:20
  • @Someprogrammerdude: I've just edited my question for including a _Minimal, Completed and Verifiable Example_... please take a look! – Morix Dev Mar 09 '17 at 12:36
  • Please prepare a debug build of Qt, build your example using that debug build, then run it under the debugger to see where exactly it crashes. Just saying that "there's a segmentation fault" is not enough. You may be facing a bug in the old version of Qt that you're using. – Kuba hasn't forgotten Monica Mar 09 '17 at 14:45
  • @KubaOber: it looks like a _loooooong_ task and I am afraid I have no time to do that right now... any other ideas? – Morix Dev Mar 09 '17 at 14:56
  • How can you even contemplate developing using a framework without having a debug build of said framework? Building Qt should take 5 minutes of your time to write the `configure` line, then it will run in the background. You do have the IDE set up to debug your target, right? Also, if you can, you should update Qt to 5.8.0 since then you can leverage [Qt Lite](http://stackoverflow.com/a/42490693/1329652) and your build will end up smaller and potentially faster too. – Kuba hasn't forgotten Monica Mar 09 '17 at 15:09
  • @KubaOber: I think that my scenario is the "normality" for the majority of programmers... I wonder to know how many Qt programmers actually have a "debug" build of Qt ready to use when it is requested... the most fanatic one probably do, but the majority of programmers simply "trust" the framework and they think they do not need a debug build of it... Take Microsoft .NET as example: anyone out there really needing a debug build of .NET for daily development? Anyway, thanks for suggestion: as soon as I can I'll prepare the debug build of Qt... meanwhile: any other ideas? – Morix Dev Mar 09 '17 at 15:18
  • .NET+CLR is different because it is a runtime environment and a framework, and the runtime has the information needed to point to your code as the source of a problem. In case of C++ frameworks, if you trigger a crash in the framework, you need a debug build to pinpoint what went wrong, in most cases - to decide whether it's your fault or not. You also should be building Qt as a part of your project's final build: that's how you're meant to use it, in fact. If you use the precompiled Qt provided by the Linux distribution, there will be debug builds for you to use so it's not an issue then. – Kuba hasn't forgotten Monica Mar 09 '17 at 15:29
  • I'd consider a normal Qt based development and CI environment to consist of multiple Qt builds, for different purposes. You're missing out on a lot of flexibility if you don't. – Kuba hasn't forgotten Monica Mar 09 '17 at 15:32
  • I'm also having this problem when I use exactly the "minimal, complete and verifiable example" in the edit of the OP, when I compile (Visual Studio) with linker option /SUBSYSTEM:WINDOWS. As this thread is stale, I'll post this as a separate question now. – Captain Normal Jan 28 '21 at 08:46

0 Answers0