QT deployed executable crashes on some computers
-
@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 returning0
. 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?
wrote on 27 Nov 2019, 09:03 last edited by Lati@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.
-
@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.
wrote on 27 Nov 2019, 09:13 last edited by JonB@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 toNULL
,numberOfElements
is set to0
, and the return value is0
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 fromgetenv()
.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 :)
41/42