uninitialized data passed to QStringList QCoreApplication::arguments()
-
@rparon said in uninitialized data passed to QStringList QCoreApplication::arguments():
int argc = 1;
This is still wrong as you pass one parameter...
No reproducer, no fix of the obvious errors so no help from my side.
@Christian-Ehrlicher said in uninitialized data passed to QStringList QCoreApplication::arguments():
@rparon said in uninitialized data passed to QStringList QCoreApplication::arguments():
int argc = 1;
This is still wrong as you pass one parameter...
No reproducer, no fix of the obvious errors so no help from my side.
the "Willingness to help" argument aside, I'm curious about your problem with the argc assignment, from a purely technical point of view.
So what if the argv list is longer than one element. The argc is an arbitrary limit that must not be greater than the number of elements in the list, lest you access out of bound memory. Sure, it is "SUPPOSE" to be the actual length of the argv list but in the context of this test, does it matter?
-
@Christian-Ehrlicher said in uninitialized data passed to QStringList QCoreApplication::arguments():
@rparon said in uninitialized data passed to QStringList QCoreApplication::arguments():
int argc = 1;
This is still wrong as you pass one parameter...
No reproducer, no fix of the obvious errors so no help from my side.
the "Willingness to help" argument aside, I'm curious about your problem with the argc assignment, from a purely technical point of view.
So what if the argv list is longer than one element. The argc is an arbitrary limit that must not be greater than the number of elements in the list, lest you access out of bound memory. Sure, it is "SUPPOSE" to be the actual length of the argv list but in the context of this test, does it matter?
@Kent-Dorfman said in uninitialized data passed to QStringList QCoreApplication::arguments():
tual length of the argv list but in the context of this test, does it matter?
The first argument is always the executable name. And I doubt it's what the first arg here is. He wants a parameter or whatever. Otherwise why fiddle around with QCoreApplication::arguments?
but we just have to guess due to a missing reproduce. -
I understand the different points of view, to clarify :
int argc = 1; const char* argv[] = {"MyDll"," "," "};is based on Qt documentation
argc must be greater than zero and argv must contain at least one valid character string, argc = 1 is a correct value.
Converting vars from local to global / extern seems to solve the problem
-
I am observing access violation exceptions (see attached screenshot) due to uninitialized data when exec() (see the code below) calls QStringList QCoreApplication::arguments(), verified in Qt 6.8.3
CODE
int argc = 1; const char* argv[] = {"MyDll"," "," "}; qapp_pt = cv_new QGuiApplication(argc, (char**) argv); if (qapp_pt == NULL) { return(false); } QQmlApplicationEngine* QmlEngine; QmlEngine = cv_new QQmlApplicationEngine(); if (QmlEngine == NULL) { return(result); } // run QMLEngine and load Main.qml, QmlEngine->load(QUrl(QStringLiteral("qrc:/GuiModule/mydll/resource/Main.qml"))); // in this version loadFromModule() doesn't work, // maybe a different CMake configuration or a different call to loadFromModule ? // QmlEngine->addImportPath("mydll/resource"); // QmlEngine->loadFromModule("GuiModule","Main"); // exception thrown here !! result = qapp_pt->exec();the code is inside a shared library (Qt project) the CMakeList.txt to create the project is
CMAKEFILE.TXT
cmake_minimum_required(VERSION 3.16) find_package(Qt6 REQUIRED COMPONENTS Quick Gui Core QmlImportScanner) qt_add_library(mydll SHARED mydll/mydllx.cpp ) qt_add_qml_module(mydll VERSION 1.28 URI GuiModule RESOURCE_PREFIX "/" NO_PLUGIN IMPORTS Quick Gui Qml Core SOURCES mydll/gxpage/test_page.cpp RESOURCES mydll/mydllresources.qrc QML_FILES mydll/resource/Main.qml ) set_target_properties(mydll PROPERTIES PREFIX "" OUTPUT_NAME "mydll" SUFFIX ".dll") # link QT-QML libraries and mylib target_link_libraries(mydll PRIVATE Qt6::Gui Qt6::Quick Qt::QuickControls2 ${CMAKE_BINARY_DIR}/mylib.lib ) set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} /MT /Ox") set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /MT /Ox") set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} /MTd") set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /MTd")DISCUSSION
Qt should initialize (by default) all the vars passed to QCoreApplication but according many tests there are exceptions...
To solve the reported problem I think there are at least two options :
-
modify qcoreapplication.cpp and recompile (from source) Qt library, the problem is that when I edit / change qcoreapplication.cpp , run configure.bat and then compile there are several errors generated, probably I can't run configure but follow some other procedure, do you know if a detailed procedure to edit / modify source in Qt library is available for review ?
-
before to call qapp_pt->exec() (see the code above) call some method in Qt library to force a reliable initialization of all vars passed to QCoreApplication, do you know if there is a method which does that ?
Thank you for help !!
@rparon said in uninitialized data passed to QStringList QCoreApplication::arguments():
const char* argv[] = {"MyDll"," "," "}; qapp_pt = cv_new QGuiApplication(argc, (char**) argv);This is always the wrong thing to do. This code is telling the compiler to allocate something as const, and then instructing it to ignore the const-ness when passing to a function that has a type signature allowing modification.
Quoting from the above link:
Such object cannot be modified: attempt to do so directly is a compile-time error, and attempt to do so indirectly (e.g., by modifying the const object through a reference or pointer to non-const type) results in undefined behavior.
https://en.cppreference.com/w/cpp/language/ub.html
- undefined behavior - There are no restrictions on the behavior of the program.
- Some examples of undefined behavior are data races, memory accesses outside of array bounds, signed integer overflow, null pointer dereference, more than one modifications of the same scalar in an expression without any intermediate sequence point(until C++11)that is unsequenced(since C++11), access to an object through a pointer of a different type, etc.
Furthermore, the QGuiApplication, the documentation explicitly mentions the possibility of modification:
Note: argc and argv might be changed as Qt removes command line arguments that it recognizes.
-
-
Hi jeremy_k,
that is an interesting point,
argc, argv date back to Unix times,
see The C programming Language, Brian W. Kernighan and Dennis M. Ritchie which includes many examples with command lines...
however it is not a normal practice to modify directly the values passed via command line so, for that purpose, any constant value should be ok... (but I am prepared to accept different opinions) -
Hi jeremy_k,
that is an interesting point,
argc, argv date back to Unix times,
see The C programming Language, Brian W. Kernighan and Dennis M. Ritchie which includes many examples with command lines...
however it is not a normal practice to modify directly the values passed via command line so, for that purpose, any constant value should be ok... (but I am prepared to accept different opinions)@rparon said in uninitialized data passed to QStringList QCoreApplication::arguments():
however it is not a normal practice to modify directly the values passed via command line
You can Google
is it normal to alter argvto find out that it is perfectly acceptable to alter this or its content. I have no comment on "normal". It is not acceptable to modify any of the actual strings' content "in place" or extend them etc., though reassigning a pointer inargv[]to point to a new string is fine.If you ever supplied a fully compilable, working, minimal repro of your situation and what exactly to change from what to what to move it from crashing to working one could comment and explain. Without that we don't know and it's guesswork as to what is going on.
-
-
JonB,
correct, standards as C99 state that parameters argc and argv and the strings pointed to by the argv array shall be modifiable by the program....
I do not know if Qt alters those values but that introduces new possible origins for that behaviour ...@JonB said in uninitialized data passed to QStringList QCoreApplication::arguments():
If you ever supplied a fully compilable, working, minimal repro of your situation and what exactly to change from what to what to move it from crashing to working one could comment and explain. Without that we don't know and it's guesswork as to what is going on.
-
Hi jeremy_k,
that is an interesting point,
argc, argv date back to Unix times,
see The C programming Language, Brian W. Kernighan and Dennis M. Ritchie which includes many examples with command lines...
however it is not a normal practice to modify directly the values passed via command line so, for that purpose, any constant value should be ok... (but I am prepared to accept different opinions)@rparon said in uninitialized data passed to QStringList QCoreApplication::arguments():
Hi jeremy_k,
that is an interesting point,The point seems to have been missed. Treating const data as non-const is undefined behavior, and the C++ standard allows a conforming implementation to do anything when UB is invoked.
Command line arguments and historical usage are irrelevant.
