Version: 1.4.2 (using KDE KDE 3.4.1) Installed from: SuSE RPMs OS: Linux I've got a large class diagram, a use case diagram, and a bunch of sequence diagrams. When I open my file, I see two bogus public operations that have been mysteriously added to two of my classes (class diagram). They are 82481() and 80543(). I look through my sequence diagrams and see that, apparently at random, some of my operations invocations have been changed to one of the aforementioned bogus operations. I change the operations back to what they should be, for example JJobList(). Then I go back to my class diagram, open up the offending classes, and remove the bogus operations. Finally, I save my file and close Umbrello. When I reopen my file... those two bogus operations are back. The same thing happens to my other Umbrello files, only with different bogus operation names that replace different operations in my sequence diagram. If I leave the bogus operations in the classes in my class diagram (but correct my sequence diagram operations to what they should be), the next time I open my file... two new bogus operations have been added to my classes!! This is driving me crazy, and I'm about to find another UML diagramming tool! Please help! Yurgen
I cannot reproduce this. Please attach your XMI file (stripped down if possible.)
Created attachment 12240 [details] The UML documentation file that contains the mysterious operations Class diagram->JJobList->92520() = mysterious operation that appears when I save and reload. Class diagram->JJobReport->92604() = mysterious operation that appears when I save and reload. Create Job Use Case->92520() should be add(...) Report Job Use Case->92604() should be JJReport(...) When I delete the mysterious operations, correct the use case diagrams, save, and reload new "mysterious" operations appear (sometimes with different combinations of digits).
I believe the problem was fixed by commit 449247 on svn.kde.org:/home/kde/branches/KDE/3.5, see also http://sourceforge.net/mailarchive/forum.php?thread_id=7960056&forum_id=472 With current umbrello from the KDE 3.5 branch, there is no problem. First I renamed the offending operations like so: JJobList::92520() -> JJobList::renamed_from_92520() and so on. Further, you mention > > Create Job Use Case->92520() should be add(...) Ah, but the add() operation already exists. Do you have two add() operations that differ in signature? If not, then the existing add() should be removed, and the "renamed_from_92520()" should really be the "add()".
That's really weird because when I load the file, I see only one JJobList::add() operation in both my class diagram and use case diagram. Perhaps the problem is that I'm using KDE 3.4.1 Level "A". I'll start downloading KDE 3.5 tonight and then mark this bug as RESOLVED if indeed the problem is resolved with the newer version.
> Perhaps the problem is that I'm using KDE 3.4.1 Level "A". > I'll start downloading KDE 3.5 tonight [...] The KDE version is not the problem; it is an Umbrello bug, and one which was fixed only fixed a few days ago in the KDE Subversion repository. Make sure to check out the current Umbrello from the 3.5 branch (see my previous post.)
Whew! I downloaded the latest bleeding-edge Umbrello (1.4.89) from the branch you recommended. After compiling and installing, I proceeded to test it with my file. I decided to play it safe and pretty much gut the file by deleting all the message lines on the sequence diagrams and all the associations between classes on the class diagram. Then I tried recreating them, only to find none of the operations within my classes (that are within packages) in the New Operation->Operation Properties->General Properties->Type combo box. I tracked down that problem to the umldoc.cpp->getConcepts() operation where I changed the "pkg->appendInterfaces(conceptList);" line to "pkg->appendClassifiers(conceptList);" (as in Umbrello 1.4.2). My solution sounds weird, I know, and is probably not correct; but it put my classes' operations back into that list box where I could select them. Finally, I recreated all the assocations between the classes and after that, the message lines in the sequence diagrams. And guess what... no more weird operations appearing out of the blue. Well, at least for a while. After saving and loading a few times and continuing to add more stuff to my file, a nice little operation named "108853" dropped by for a visit. He also appeared on my sequence diagram in the place of a legitimate operation. I tried redoing the class (on the class diagram) in which he appeared and the sequence diagram in which the class was used, but to no avail. Friendly "108853" keeps coming back for tea and coffee. I just hope he doesn't start inviting his friends. So what do I do now?
SVN commit 451193 by okellogg: CCBUG:110843 - Yurgen Wolfgang wrote: > I tracked down that problem to the umldoc.cpp->getConcepts() operation > where I changed the "pkg->appendInterfaces(conceptList);" line to > "pkg->appendClassifiers(conceptList);" (as in Umbrello 1.4.2). > [...] Congratulations, you have just fixed an Umbrello bug ! M +1 -0 THANKS M +1 -1 umbrello/umldoc.cpp --- branches/KDE/3.5/kdesdk/umbrello/THANKS #451192:451193 @@ -65,6 +65,7 @@ Brian Thomas <brian.thomas @gsfc.nasa.gov> Jean Vittor <jean.vittor @wanadoo.fr> Stefan Walter <sw @gegenunendlich.de> +Yurgen Wolfgang <raptorsforever @softhome.net> Maciej J. Woloszyk <mat @esi.com.pl> Tobias Wulff <Tobias-Wulff @codeeye.de> --- branches/KDE/3.5/kdesdk/umbrello/umbrello/umldoc.cpp #451192:451193 @@ -2378,7 +2378,7 @@ conceptList.append((UMLClassifier *)obj); } else if (includeNested && ot == ot_Package) { UMLPackage *pkg = static_cast<UMLPackage *>(obj); - pkg->appendInterfaces(conceptList); + pkg->appendClassifiers(conceptList); } } return conceptList;
> After saving and loading a few times and continuing to add more stuff to > my file, a nice little operation named "108853" dropped by for a visit. Please again attach your file.
Created attachment 12278 [details] File, trimmed down, but containing mysterious operation Tried to reduce the size of my file for uploading, but Umbrello crashes every time I delete a class. So, here's the file at about 1/2 MB. Notice Class Diagram->JJobReport->108853() and Report Job Use Case->108853(). The later should be JJobReport's constructor. Operation 108853() just appears out of no where.
Created attachment 12283 [details] The same file but cleaned. If you could give more details about the exact steps that you did which resulted in the bogus operation that would help a lot. > Tried to reduce the size of my file for uploading, but Umbrello > crashes every time I delete a class. Wow. I'll try to fix that one first. As a temporary workaround, try disabling Undo (in the Umbrello general settings.)
Created attachment 12296 [details] Latest copy of the uml example file, with the bogus operation 1) I downloaded the latest file you posted ("The same file but cleaned.") and opened it with Umbrello 1.4.89. All the operations, classes, use cases, etc. were in order. 2) Then I saved the file and closed Umbrello. 3) After re-opening the file, all the operations, etc. were still in order. 4) Then I changed the Report Job Use Case->JJobReport(...) synchronous message (that ties the actor to the JJobReport class) to JJobReport->sendThis(). 5) After saving, closing Umbrello, and then reopening the file, a new operation called 118189() appeared in the class diagram->JJobReport class. In addition, the Report Job Use Case->sendThis() synchronous message, that I changed in the previous step, now appears as Report Job Use Case->118189(). Everything else appears to be in order. I am uploading the latest file, the only changes being those made in step 4 above resulting in step 5 above.
Thanks for the info. I fixed the crash-on-any-delete in my local svn copy and have done many further cleanups but I cannot reproduce the bogus operation. At the moment I don't know whether this is due to my cleanups. Checkin to follow in a few days (when I have KDE repo access.)
SVN commit 453995 by okellogg: CCBUG:110843 - Fix for comment #9 From Yurgen Wolfgang 2005-08-20 15:22 > Tried to reduce the size of my file for uploading, but Umbrello > crashes every time I delete a class. M +1 -1 associationwidget.cpp M +7 -8 umlcanvasobject.cpp M +5 -4 umldoc.cpp M +1 -4 umlview.cpp --- branches/KDE/3.5/kdesdk/umbrello/umbrello/associationwidget.cpp #453994:453995 @@ -778,7 +778,7 @@ if (assoc && umla == assoc) return; - umla->disconnect(this); + //umla->disconnect(this); //Qt does disconnect automatically upon destruction. umla->nrof_parent_widgets--; // we are the last "owner" of this association, so delete it --- branches/KDE/3.5/kdesdk/umbrello/umbrello/umlcanvasobject.cpp #453994:453995 @@ -72,16 +72,15 @@ for (UMLAssociationListIt ait(m_AssocsList); ait.current(); ++ait) { UMLAssociation *assoc = ait.current(); umldoc->slotRemoveUMLObject(assoc); - UMLCanvasObject *other = NULL; UMLObject* objA = assoc->getObject(Uml::A); UMLObject* objB = assoc->getObject(Uml::B); - if (objA == this) - other = dynamic_cast<UMLCanvasObject*>(objA); - else - other = dynamic_cast<UMLCanvasObject*>(objB); - if (other) - other->removeAssociation(assoc); - delete assoc; + UMLCanvasObject *roleAObj = dynamic_cast<UMLCanvasObject*>(objA); + if (roleAObj) + roleAObj->removeAssociation(assoc); + UMLCanvasObject *roleBObj = dynamic_cast<UMLCanvasObject*>(objB); + if (roleBObj) + roleBObj->removeAssociation(assoc); + //delete assoc; cannot do this! AssociationWidgets may exist! } m_AssocsList.clear(); } --- branches/KDE/3.5/kdesdk/umbrello/umbrello/umldoc.cpp #453994:453995 @@ -281,12 +281,12 @@ if (m_objectList.count() > 0) { // clear our object list. We do this explicitly since setAutoDelete is false for the objectList now. for(UMLObject * obj = m_objectList.first(); obj != 0; obj = m_objectList.next()) - ; //obj->deleteLater(); + delete obj; m_objectList.clear(); } if (m_stereoList.count() > 0) { for (UMLStereotype *s = m_stereoList.first(); s; s = m_stereoList.next()) - ; //s->deleteLater(); + delete s; m_stereoList.clear(); } } @@ -1448,11 +1448,12 @@ } } UMLPackage* pkg = umlobject->getUMLPackage(); - if (pkg) { + if (pkg) { pkg->removeObject(umlobject); + } else { + m_objectList.remove(umlobject); } emit sigObjectRemoved(umlobject); - m_objectList.remove(umlobject); } setModified(true); } --- branches/KDE/3.5/kdesdk/umbrello/umbrello/umlview.cpp #453994:453995 @@ -2003,11 +2003,8 @@ m_pMoveAssoc = 0; } - // Remove the association in this view - but set the document - // modified BEFORE physically deleting it because it is still - // needed for an entry in the undo stack (when Undo is enabled.) - m_pDoc->setModified(); m_AssociationList.remove(pAssoc); // will delete our association + m_pDoc->setModified(); } void UMLView::removeAssocInViewAndDoc(AssociationWidget* a) {
Created attachment 12396 [details] bug110843-cleaned.xmi I have once more cleaned out residual artefacts from your file. With this file, and after the commit of a few minutes ago, I cannot recreate your bogus operation. Could you please try again, thanks.
*** Bug 111767 has been marked as a duplicate of this bug. ***
*** Bug 108849 has been marked as a duplicate of this bug. ***
I have just moved, so things have been kind of hectic; tomorrow I am having my ADSL connected, and after that I'll be able to post the file. Sorry for the delay.
Finally... my Internet connection is up-and-running. I'm downloading the latest commit of umbrello. I'll test it with the file and upload the results as soon as I can. Thanks.
I compiled and tried to test Umbrello with the file, but Umbrello crashes before even bringing up the GUI. It gives a signal 11 (SIGSEGV) error. The backtrace is: Using host libthread_db library "/lib64/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 46912560942272 (LWP 23073)] [KCrash handler] #3 0x00002aaaae6c6300 in strlen () from /lib64/tls/libc.so.6 #4 0x00002aaaacbfd0ad in internalLatin1ToUnicode () from /usr/lib/qt3/lib64/libqt-mt.so.3 #5 0x00002aaaacbfd111 in QString::fromLatin1 () from /usr/lib/qt3/lib64/libqt-mt.so.3 #6 0x00002aaaacbfdaee in QString::fromAscii () from /usr/lib/qt3/lib64/libqt-mt.so.3 #7 0x00000000005b4f11 in WorkToolBar::loadPixmaps () #8 0x00000000005b5dd4 in WorkToolBar::WorkToolBar () #9 0x000000000055ffb8 in UMLApp::initView () #10 0x0000000000563ce3 in UMLApp::UMLApp () #11 0x0000000000538acf in main () Suggestions?
As this is not happening here, and the backtrace is not really helpful, I kindly request your help: * configure Umbrello with --enable-debug=full * make clean; make * gdb umbrello (gdb) break worktoolbar.cpp:305 (gdb) run ... Step thru the loop for loading the pixmap files, and report at which of the files the crash happens. Many thanks for your assistance.
Ok, I did that. After stepping through dozens of lines of code, nothing happened. Perhaps the breakpoint is too far from the problem? Also, when running umbrello, here's the report on the bash prompt: umbrello: WorkToolBar::loadPixmaps: n_buttonInfos = 51 QImage::convertDepth: Image is a null image QPixmap::convertFromImage: Cannot convert a null image QCursor: Cannot create bitmap cursor; invalid bitmap(s) QImage::convertDepth: Image is a null image QPixmap::convertFromImage: Cannot convert a null image QCursor: Cannot create bitmap cursor; invalid bitmap(s) QImage::convertDepth: Image is a null image QPixmap::convertFromImage: Cannot convert a null image QCursor: Cannot create bitmap cursor; invalid bitmap(s) KCrash: Application 'umbrello' crashing... Maybe that will help. Then again... maybe not!
> umbrello: WorkToolBar::loadPixmaps: n_buttonInfos = 51 > [...] > QPixmap::convertFromImage: Cannot convert a null image > QCursor: Cannot create bitmap cursor; invalid bitmap(s) > KCrash: Application 'umbrello' crashing... Strange. According to your backtrace, the crash happens in WorkToolBar::loadPixmaps(). Now that you have built umbrello with debug info, could you again attach a backtrace? (The backtrace should show more info now, e.g. exact line numbers and source file names.) Thanks.
Oh nevermind. I think I found the culprit, an array size miscalculation in loadPixmaps(see bug 112567.) Please try again.
When I add messages to an operation with an argument (both synchronized and asynchronized), in a sequence diagram, I get and added duplicate of the chosen operation - an operation with almost the same name. I get this in a model with just two classes. When the operation has no argument, the duplicate does not appear! The original operation is: "an_op(an_arg : int)" The duplicate is: "an_op(an_arg : int)an_arg : int" Steps to reproduce: 1. Create a new empty model. 2. Add two classes, "c1" and "c2". 3. Add an operation "an_op" with an argument "an_arg" (type "int") to "c2". 4. Create a sequence diagram and drag and drop "c1" and then "c2" onto it. 5. "Draw" a message from "c1" to "c2" and choose "an_op" as the operation. Now the duplicate operation is added to "c2"! Version: 1.4.90 (using KDE 3.4.2-0.fc4.1 RedHat)
SVN commit 462698 by okellogg: parseOperation(): Commit #460377 was bad. The search pattern for delimiting the op name now includes everything up to (and excluding) the opening parenthesis. CCBUG:110843 - This fixes Comment #24 From Emil Karlen. M +5 -6 model_utils.cpp --- branches/KDE/3.5/kdesdk/umbrello/umbrello/model_utils.cpp #462697:462698 @@ -344,21 +344,20 @@ if (m.isEmpty()) return PS_Empty; /** - * We don't apply programming-language style syntax checking on the name + * The search pattern includes everything until the opening parenthesis * because UML also permits non programming-language oriented designs * using narrative names, for example "check water temperature". - QRegExp pat( "^(\\w+)" ); + */ + QRegExp pat( "^([^\\(]+)" ); int pos = pat.search(m); if (pos == -1) return PS_Illegal_MethodName; desc.m_name = pat.cap(1); - */ // Remove possible empty parentheses () m.remove( QRegExp("\\s*\\(\\s*\\)") ); - desc.m_name = m; desc.m_pReturnType = NULL; - QRegExp pat( ":\\s*(\\w[\\w\\. ]*)$" ); - int pos = pat.search(m); + pat = QRegExp( ":\\s*(\\w[\\w\\. ]*)$" ); + pos = pat.search(m); if (pos != -1) { // return type is optional QString retType = pat.cap(1); if (retType != "void") {
Created attachment 12655 [details] My "real" umbrello model. bziped. When working on my real model the problem with added duplicate operations when making a message in a sequence diagram is still there. How to reproduce: 1. Select the sequence diagram "sekv-UpdateOne" (already selected). 2. Scroll the tree view so that you se the class webdblib::oformat::OFormatter. Open it so that you see its methods (it got one attribute and three methods) 3. "Draw" and synchronized message from "wdbent : Entity" (the green entity at the top) to "lOMFPKs[i]" : OFormatter" (the green object at the bottom (these are the only two green objects on the diagram). I draw the message as the last message on the diagram. 4. Select the operation "SettAttr(av : ...". Now a new operation "SetAttr(av : )" appears in OFormatter! Version: 1.4.90 (using KDE 3.4.2-0.fc4 RedHat), commit #462891
I used the file you (Oliver) uploaded recently. It did not seem to produce the problems we've been experiencing. However, because there's not much in that particular file (it's quite trimmed down), I was not able to experiment with it much. So, I loaded my original Umbrello file, deleted the operations that were bogus, and then saved and closed the file. When I re-opened it, a host of new bogus operations were in four of the classes. I've uploaded my complete Umbrello file. I would suggest you: 1) load it with Umbrello, 2) delete the bogus operations (they have weird numeric names like 85751(), 27576(), etc.), 3) save and close Umbrello down, and 4) then re-open the file with Umbrello. You should see a whole new set of bogus operations. I won't be able to help anymore with tracking down this bug because I have ported the documentation for my application to Bouml. I did not think fixing this bug would take so much time. Since the only time I have to work on my program is afterhours, and even then only a few hours a week, I need to devote those precious hours to actual development. Good luck, and thanks for all the time and effort you've put towards this!
Created attachment 12667 [details] Complete UML document w/bogus operations
SVN commit 463046 by okellogg: findOperation(): Avoid comparing types by name because getTypeName() has its own smarts about scope prefixing. Instead, use pointer comparison. Thanks to Emil Karlen and Yurgen Wolfgang for their input. BUG:110843 M +2 -2 ChangeLog M +4 -6 umbrello/classifier.cpp --- branches/KDE/3.5/kdesdk/umbrello/ChangeLog #463045:463046 @@ -11,8 +11,8 @@ * Bugs fixed / wishes implemented (see http://bugs.kde.org) 57588 57672 58809 66461 67120 67719 72016 79433 87252 88117 97162 101550 105564 108223 109591 109636 110073 110216 110231 110379 -111088 111470 111502 111759 111768 112017 112292 112293 112333 112531 -112552 112936 112991 112992 +110843 111088 111470 111502 111759 111768 112017 112292 112293 112333 +112531 112552 112936 112991 112992 Version 1.4.2 (maintenance release) --- branches/KDE/3.5/kdesdk/umbrello/umbrello/classifier.cpp #463045:463046 @@ -111,7 +111,6 @@ UMLOperationList list = findOperations(name); if (list.count() == 0) return NULL; - const bool caseSensitive = UMLApp::app()->activeLanguageIsCaseSensitive(); // If there are operation(s) with the same name then compare the parameter list const int inputParmCount = params.count(); UMLOperation* test = NULL; @@ -125,13 +124,12 @@ int i = 0; for (; i < pCount; ++i) { Model_Utils::NameAndType_ListIt nt(params.at(i)); - UMLObject *c = (*nt).m_type; - QString typeName = testParams->at(i)->getTypeName(); + UMLClassifier *c = dynamic_cast<UMLClassifier*>((*nt).m_type); + UMLClassifier *testType = testParams->at(i)->getType(); if (c == NULL) { //template parameter - if (typeName != "class") + if (testType->getName() != "class") break; - } else if ((caseSensitive && typeName != c->getName()) || - (!caseSensitive && typeName.lower() != c->getName().lower())) + } else if (c != testType) break; } if (i == pCount)