[Uml-devel] [Bug 73926] Unable to change the specification of an operation

Sebastian Stein seb_stein at gmx.de
Sun Feb 1 06:39:09 UTC 2004

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

------- Additional Comments From seb_stein at gmx.de  2004-02-01 15:38 -------
Subject: Re: [Uml-devel]  New: Unable to change the specification of an operation

Jonathan Riddell <jr at jriddell.org> [040201 10:27]:
> http://bugs.kde.org/show_bug.cgi?id=73926      
>            Summary: Unable to change the specification of an operation
>  ...
> Program received signal SIGSEGV, Segmentation fault.
> 0x080ef9ec in UMLClassifier::checkOperationSignature(QString,
> QPtrList<UMLAttribute>*) ()
> <Backtrace>
> (gdb) bt
> #0  0x080ef9ec in UMLClassifier::checkOperationSignature(QString,
> QPtrList<UMLAttribute>*) ()
> #1  0x0814cc54 in UMLDoc::createOperation(UMLClassifier*, QString const&,
> QPtrList<UMLAttribute>*) ()
> #2  0x0814bebb in UMLDoc::createChildObject(UMLObject*, Uml::UMLObject_Type)

I've looked a little bit into this problem. Well, the main reason for the
crash is, that the newly created operation doesn't have a classifier, which
seems to be intended by the real hacker, who added the following lines to

UMLOperation* UMLDoc::createOperation(UMLClassifier* classifier, const QString &name /*=null*/, UMLAttributeList *params )

      op = new UMLOperation( NULL, "", getUniqueID());
                             ^^^^ no classifier

      op->setName( classifier->uniqChildName(Uml::ot_Operation) );
      //hack, make op a child of classifier without really adding it as
      //this makes the Op.Dialog smoother in case of name conflicts
      // classifier->insertChild( op );
      ^^^^ the explanation I don't understand

which is called by

UMLDoc::createChildObject(UMLObject*, Uml::UMLObject_Type)

That's why

dynamic_cast<UMLClassifier*>( m_pOperation->parent() );

in bool UMLOperationDialog::apply() always returns 0. But without the
classifier we can't iterate through all operations to check if an operation
with the same signature exists. That's why the crash occurs. Maybe the other
problem is also related to this.

So whoever did this hack, please stand up and show us how to completly
"smooth" the Op.Dialog!


More information about the umbrello-devel mailing list