| Summary: | CodeGenerator* UMLApp::m_codegen is never destroyed | ||
|---|---|---|---|
| Product: | [Applications] umbrello | Reporter: | Robert Hairgrove <code> |
| Component: | general | Assignee: | Umbrello Development Group <umbrello-devel> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | Git | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Robert Hairgrove
2021-11-10 12:20:37 UTC
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.. |