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. QT deployed executable crashes on some computers
Forum Updated to NodeBB v4.3 + New Features

QT deployed executable crashes on some computers

Scheduled Pinned Locked Moved Solved General and Desktop
42 Posts 9 Posters 10.7k 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.
  • J JonB
    27 Nov 2019, 08:28

    @Lati
    For the record, getenv() has been in the C runtime libraries since the 1970s(!) There has to be a way for it to tell you that the selected environment variable does not exist (without crashing!), and that is of course by returning 0. I and millions of other coders have been using that behaviour ever since :)

    In your case, whoever wrote the code which does not check for that will doubtless have been working in an environment where that ProgramXROOT variable did always exist, and hence never witnessed the unanticipated behaviour.

    OOI, how have you resolved this? Did you actually change that library's code to fix and recompile, or have you just told your end users they must have that environment variable defined?

    L Offline
    L Offline
    Lati
    wrote on 27 Nov 2019, 09:03 last edited by Lati
    #41

    @JonB I am not one of that millions of coders (or even if I used it, I never had problems).

    In the code, I replaced the getenv part using _dupenv_s as following (which will be valid with the next release):

        char* buf = nullptr;
        size_t sz = 0;
        if (_dupenv_s(&buf, &sz, "programXROOT") == 0 && buf != nullptr)
        {
            programXRootDirectory = buf;
            free(buf);
        }
        else
        {
            QMessageBox msgBox;
            msgBox.setText("Environmental variable is missing!");
            msgBox.exec();
        }
    

    Actually, after installation of this application, user has to create this environmental variable before starting the application. And seems like all the users have created the variable and there was no issue so far. But if a user would forget about this, it would be nightmare to find out the reason.

    J 1 Reply Last reply 27 Nov 2019, 09:13
    0
    • L Lati
      27 Nov 2019, 09:03

      @JonB I am not one of that millions of coders (or even if I used it, I never had problems).

      In the code, I replaced the getenv part using _dupenv_s as following (which will be valid with the next release):

          char* buf = nullptr;
          size_t sz = 0;
          if (_dupenv_s(&buf, &sz, "programXROOT") == 0 && buf != nullptr)
          {
              programXRootDirectory = buf;
              free(buf);
          }
          else
          {
              QMessageBox msgBox;
              msgBox.setText("Environmental variable is missing!");
              msgBox.exec();
          }
      

      Actually, after installation of this application, user has to create this environmental variable before starting the application. And seems like all the users have created the variable and there was no issue so far. But if a user would forget about this, it would be nightmare to find out the reason.

      J Online
      J Online
      JonB
      wrote on 27 Nov 2019, 09:13 last edited by JonB
      #42

      @Lati
      Again for the record, the _dupenv_s (which btw is MSVC-only) you mention has nothing to do with the issue you are talking about. The extra parameters it takes are to do with copying the value, if found, into your own buffer. If it's not found:

      If the variable is not found, then buffer is set to NULL, numberOfElements is set to 0, and the return value is 0 because this situation is not considered to be an error condition.

      So the issue will rear its head again if code later tries to dereference the buf from the &buf passed in. Just as with the return result from getenv().

      Purely as a by-the-by, I presume you are aware in the code you show (which perhaps is only intended as an example):

              programXRootDirectory = buf;
              free(buf);
      

      This would not be a good idea --- programXRootDirectory is left pointing to freed memory! You'll get a different error/crash/behaviour if you then dereference that :)

      1 Reply Last reply
      2

      41/42

      27 Nov 2019, 09:03

      • Login

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