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

[Esben Mose Hansen]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
      
http://bugs.kde.org/show_bug.cgi?id=73926      




------- Additional Comments From esben despammed com  2004-03-18 09:12 -------
Created an attachment (id=5261)
 --> (http://bugs.kde.org/attachment.cgi?id=5261&action=view)
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.