The UMLApp member variable "CodeGenerator* UMLApp::m_codegen" is apparently never destroyed once it is created. The base class CodeGenerator is derived from QObject, but it is always created without a parent and does not initialize the base QObject in its constructor. The containing class UMLApp does not delete this pointer in its destructor. Have I overlooked something here?
Following up on this, it seems that there are very many instances where the parent-child relationship between QObject/QWidget and derived classes is not respected: 1. Either the derived class does not initialize its base class QObject or QWidget with a "parent" object, in which case it must be manually deleted (and is sometimes forgotten as in the case of CodeGenerator classes); 2. The derived class DOES initialize its base class with a parent, but it is deleted nonetheless manually somewhere else (as in the class "DiagramsWindow" -- the class UMLAppPrivate, derived from QObject, contains a pointer "diagramsWindow" which it creates in its member initialization list on line 80 and passes "this" as the parent. However, the destructor of UMLAppPrivate ALSO deletes the same pointer, although QObject will delete all of its children on application shutdown. This is certainly cause for a lot of strange crashes and/or memory leaks.
(In reply to Robert Hairgrove from comment #1) > (snip...) > a pointer "diagramsWindow" which it creates in its member initialization > list on line 80 and passes "this" as the parent. > (snip) This refers to line 80 of the file "umlappprivate.h".
OK, this member is deleted when the UMLApp::queryClose() event is called by calling the UMLDoc::closeDocument() method which calls UMLApp::setGenerator() with the argument "Uml::ProgrammingLanguage::Reserved". Marking this as RESOLVED -- NOT A BUG..