Subject: Re: [Uml-devel]  New: Unable to change the specification of an operation

Jonathan Riddell <jr@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
      //operation
      //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!

Steinchen

*** Bug 74247 has been marked as a duplicate of this bug. ***

*** Bug 74251 has been marked as a duplicate of this bug. ***

*** Bug has been marked as fixed ***.

The bug isn't fixed yet.
Umbrello doesn't crash with a segfault any more, but it still complains with the error dialog box, whenever you try to modify an existing operation:

<quote>
An operation with that signature already exists in <classname>

Choose a different name or parameter list.
</quote>

Torben H. Nielsen <torben.nielsen@rocketmail.com> [040213 09:35]:
> The bug isn't fixed yet.
> Umbrello doesn't crash with a segfault any more, but it still complains
> with the error dialog box, whenever you try to modify an existing
> operation:

What version are you using? The fixes are only in the latest CVS version
available. Please give a step by step report, how to reproduce the problem.

Steinchen

*** Bug 75071 has been marked as a duplicate of this bug. ***

I'm using CVS HEAD on KDE 3.1.4

1) Create new diagram
2) Create new class
3) Double-click the new class to open Properties
4) Select operations
5) Create a new operation & close the operation property window with OK
6) Try to modify the newly created operation, when you press OK 
a message box pops up the text I quoted yesterday.

Yes, you are right, you can not change the operation again, but hey it doesn't crash anymore ;-)

I've looked a bit into this one:

The problem is that UMLClassifier::checkOperationSignature() doesn't know when it is checking an operation against itself.

Created attachment 4708 [details]
Allow modification of operations

I believe Oliver has now fixed this in CVS. I dont have any troubles
anymore.

*** Bug 75387 has been marked as a duplicate of this bug. ***

*** Bug 75647 has been marked as a duplicate of this bug. ***

Created attachment 5261 [details]
Fix crash in UMLDoc::createOperation(UMLClassifier*, QString const&, QPtrList<UMLAttribute>*)

This bug still isn't fixed in CVS as of today (2004-03-18). To reproduce:

1. Create a new project: Press Ctrl-N
2. Select the "Class" action from the toolbar and press anywhere on the default
class diagram to create a class. Accept the given name.
3. Rightclick on the class in the tree view. Select new->operation, and press
enter to accept the given name.
4. Rightclick on the class (again), Select new->operation, and edit the name to
be the same as in 3 (new_operation for me)
5. Select "Yes" when the diaglog titled "Name Not Unique" appears.

Backtrace:
#1  0x0815da50 in  (this=0x83c4888, classifier=0x848ca88, name=@0xbfffe6c0,
params=0x0)
    at umldoc.cpp:877
#2  0x0816ce5f in UMLListView::createChildUMLObject(UMLListViewItem*,
Uml::UMLObject_Type) (this=0x83d27c0, item=0x847f1e8, type=ot_Operation) at
umllistview.cpp:1875
#3  0x0816c8cd in UMLListView::slotItemRenamed(QListViewItem*, int)
(this=0x83d27c0, item=0x847f1e8) at umllistview.cpp:1760
#4  0x0817176e in UMLListViewItem::okRename(int) (this=0x847f1e8, col=0) at
umllistviewitem.cpp:267
#5  0x40c9c813 in QListView::eventFilter(QObject*, QEvent*) () from
/usr/qt/3/lib/libqt-mt.so.3
#6  0x40bc161a in QObject::activate_filters(QEvent*) () from
/usr/qt/3/lib/libqt-mt.so.3
#7  0x40bc152a in QObject::event(QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3
#8  0x40bf6042 in QWidget::event(QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3
#9  0x40c80244 in QLineEdit::event(QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3
#10 0x40b6a43d in QApplication::internalNotify(QObject*, QEvent*) () from
/usr/qt/3/lib/libqt-mt.so.3
#11 0x40b69cc1 in QApplication::notify(QObject*, QEvent*) () from
/usr/qt/3/lib/libqt-mt.so.3
#12 0x40758c54 in KApplication::notify(QObject*, QEvent*) () from
/usr/kde/3.2/lib/libkdecore.so.4
#13 0x40b06ae6 in QETWidget::translateKeyEvent(_XEvent const*, bool) () from
/usr/qt/3/lib/libqt-mt.so.3
#14 0x40b028dd in QApplication::x11ProcessEvent(_XEvent*) () from
/usr/qt/3/lib/libqt-mt.so.3
#15 0x40b18858 in QEventLoop::processEvents(unsigned) () from
/usr/qt/3/lib/libqt-mt.so.3
#16 0x40b7cc7b in QEventLoop::enterLoop() () from /usr/qt/3/lib/libqt-mt.so.3
#17 0x40b7cb24 in QEventLoop::exec() () from /usr/qt/3/lib/libqt-mt.so.3
#18 0x40b6a690 in QApplication::exec() () from /usr/qt/3/lib/libqt-mt.so.3
#19 0x0813bde7 in main (argc=1, argv=0xbffff4b4) at main.cpp:86

The problem is that while the UMLClassifier::checkOperationSignature() accepts
a pointer to the parameter lists, it doesn't actually handle this case.
UMLDoc::createOperation() calls checkOperation() with null, which results in a
crash. 

The attached patch fixed this by checking & handling a null parameter
reasonably. 

Commit/comment/ignore as you see fit.

Esben's patch has been applied and the problem seems to be fixed again.  Thanks very much.

Adding an operation through the list view brings up a dialogue box which it shouldn't but that's a different issue.