Details
-
Bug
-
Resolution: Incomplete
-
Not Evaluated
-
4.8.0, 4.8.1
-
None
-
g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50) # g++ --version
2.6.18-274.18.1.el5PAE GNU/Linux # uname --operating-system --kernel-release
Qt 4.8.1 with the configuration option -debug
-
8f22e4bed8973758ef175f4d5d7f725009db9eb6 (4.8)
Description
I have an application that trips a Qt assert when a user goes back and forth through its wizard such that some wizard fields that are initially created are no longer needed. Qt does appear to detect a need to clean up and calls the following routine in src/gui/dialogs/qwizard.cpp:
> void QWizardPrivate::_q_handleFieldObjectDestroyed(QObject *object)
This routine finds the field to be deleted and then executes the following two lines:
> fieldIndexMap.remove(field.name);
> it = fields.erase(it);
where field is a reference to "*it" and "it" points to the field to be destroyed. this->fieldIndexMap apparently is to contain a mapping from a field name to to its index in this->fields. (I base this statement on the source code for QWizard::field.) Therefore, these two lines appear to leave this->fields and this->fieldIndexMap in an inconsistent state. Specifically, because removing an entry from the map does not also shift all the values in the map higher than the value removed down by one.
So if we initially have the following mapping ...
"field0" -> 0,
"field1" -> 1, and
"field2" -> 2
with fields of size 3. After destruction of "field1" we have ...
"field0" -> 0, and
"field2" -> 2
with fields of size 2. Now attempts to look up "field2" using QWizard::field will have an out of bounds error and core dump because an attempt to access this->fields[2] will be made. It should be in my understanding accessing this->fields[1], but does not because the mapping is no longer correct.
So that is my theory that there is in fact a bug in QWizardPrivate::_q_handleFieldObjectDestroyed.
I have a attached a source file that reproduces this failure using the QTestLib framework.