Version: 1.4 (using KDE KDE 3.4.1) Installed from: Debian testing/unstable Packages OS: Linux I have a few XMI files which for some reason, when I open them in this version of umbrello, cause a dialog to pop up saying "new class", and at this point, the application crashes if I respond at all to the dialog. This only happens when I open from the command line - i.e. umbrello badfile.xmi If I run umbrello and do File->Open, I can open badfile.xmi, and it pops up the same dialogs, but this time, after responding to them, the application DOES NOT crash. Using host libthread_db library "/lib/tls/libthread_db.so.1". `system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1231142784 (LWP 22103)] [KCrash handler] #3 0xb71e7e6d in QListViewItem::QListViewItem () from /usr/lib/libqt-mt.so.3 #4 0x081b0f7c in UMLListViewItem (this=0x87598c0, parent=0x87598c0, name=@0xbfffd350, t=lvt_Operation, o=0x86b51e0) at umllistviewitem.cpp:67 #5 0x081a5220 in UMLListView::childObjectAdded (this=0x84f53d8, obj=0x86b51e0, parent=0x87598c0) at umllistview.cpp:689 #6 0x081a513d in UMLListView::childObjectAdded (this=0x84f53d8, obj=0x87598c0) at umllistview.cpp:674 #7 0x081af5a1 in UMLListView::qt_invoke (this=0x84f53d8, _id=109, _o=0xbfffd450) at qucom_p.h:312 #8 0xb710c71c in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #9 0x081ba5a9 in UMLObject::childObjectAdded (this=0x86b4c50, t0=0x87598c0) at umlobject.moc:112 #10 0x0810e47d in UMLClassifier::resolveRef (this=0x86b4c50) at classifier.cpp:256 #11 0x08199eef in UMLDoc::resolveTypes (this=0x8435f70) at umldoc.cpp:2216 #12 0x0819b88d in UMLDoc::loadExtensionsFromXMI (this=0x8435f70, node=@0xbfffd9a0) at umldoc.cpp:2380 #13 0x081995d9 in UMLDoc::loadFromXMI (this=0x8435f70, file=@0xbfffd920, encode=0) at umldoc.cpp:2078 #14 0x0818ced2 in UMLDoc::openDocument (this=0x8435f70, url=@0x0) at umldoc.cpp:510 #15 0x08180bd8 in UMLApp::openDocumentFile (this=0x842e438, url=@0xbfffddc0) at uml.cpp:483 #16 0x08159310 in main (argc=141924544, argv=0x87598c0) at main.cpp:79
I tried with a dozen XMI files of mine but cannot confirm this on branches/KDE/3.5/kdesdk. Could you attach a file for which this happens to you?
Created attachment 12103 [details] to reproduce the crash
Oh yeah, hard to overlook now :)
SVN commit 443365 by okellogg: resolveRef(): Temporarily use ClassImport::createUMLObject() for its scope handling until the latter is merged into UMLDoc::createUMLObject(). The problem surfaces when dealing with old Umbrello files where the type name was saved in the "type" attribute (of operation parameters etc.) rather than the xmi.id of the model object of the attribute type. Import of old files is still not perfect - it tends to create duplicated model objects for the types. I'll try to resolve that next. BUG:110216 M +2 -1 ChangeLog M +10 -1 umbrello/umlobject.cpp --- branches/KDE/3.5/kdesdk/umbrello/ChangeLog #443364:443365 @@ -9,7 +9,8 @@ * Automatic Diagram Layout (67059, not yet closed) * Bugs fixed / wishes implemented (see http://bugs.kde.org) -57588 58809 67719 72016 79433 87252 88117 97162 105564 108223 109591 109636 + 57588 58809 67719 72016 79433 87252 88117 97162 105564 108223 +109591 109636 110216 Version 1.4.2 (maintenance release) --- branches/KDE/3.5/kdesdk/umbrello/umbrello/umlobject.cpp #443364:443365 @@ -22,6 +22,7 @@ #include "package.h" #include "stereotype.h" #include "model_utils.h" +#include "classimport.h" UMLObject::UMLObject(const UMLObject * parent, const QString &name, Uml::IDType id) : QObject(const_cast<UMLObject*>(parent), "UMLObject" ) { @@ -395,6 +396,8 @@ // Assume we're dealing with the older Umbrello format where // the type name was saved in the "type" attribute rather // than the xmi.id of the model object of the attribute type. + if (m_SecondaryId == "const QModelIndex&") + kdDebug() << "Yow! const QModelIndex&" << endl; m_pSecondary = pDoc->findUMLObject( m_SecondaryId, Uml::ot_UMLObject, this ); if (m_pSecondary) { m_SecondaryId = ""; @@ -405,12 +408,18 @@ // of on-the-fly scope creation: if (m_SecondaryId.contains("::")) { m_SecondaryId.replace("::", "."); - m_pSecondary = pDoc->findUMLObject( m_SecondaryId, Uml::ot_UMLObject, this ); + // TODO: Merge ClassImport::createUMLObject() into UMLDoc::createUMLObject() + m_pSecondary = ClassImport::createUMLObject(Uml::ot_UMLObject, m_SecondaryId, NULL); if (m_pSecondary) { m_SecondaryId = ""; maybeSignalObjectCreated(); + kdDebug() << "UMLObject::resolveRef: Created a new type for " << m_SecondaryId + << " using ClassImport::createUMLObject()" << endl; return true; } + kdError() << "UMLObject::resolveRef: ClassImport::createUMLObject() " + << "failed to create a new type for " << m_SecondaryId << endl; + return false; } kdDebug() << "UMLObject::resolveRef: Creating new type for " << m_SecondaryId << endl;
Created attachment 12108 [details] bug110216-narrowed.xmi For those interested in the bug resolution process: I narrowed down Alan's XMI attachment to the core of the problem. Two <UML:Operation>s happen to mention the same scoped type name in their "type" attribute. (The same problem also happened when this scoped name was mentioned in two <UML:Attribute>s or <UML:Parameter>s.)
SVN commit 443596 by okellogg: CCBUG:110216 - I don't know how it could happen, but somehow this file slipped through the cracks upon the previous commit. M +8 -3 umllistview.cpp --- branches/KDE/3.5/kdesdk/umbrello/umbrello/umllistview.cpp #443595:443596 @@ -740,14 +740,19 @@ void UMLListView::childObjectAdded(UMLObject* obj, UMLObject* parent) { Uml::Object_Type ot = obj->getBaseType(); - /* kdDebug() << "UMLListView::childObjectAdded(" << obj->getName() - << ", type " << ot << "): ID is " << obj->getID() << endl; - */ if (ot == Uml::ot_Stereotype || m_bIgnoreChildCreationSignal) { return; } if (!m_bCreatingChildObject) { UMLListViewItem *parentItem = findUMLObject(parent); + if (parentItem == NULL) { + kdDebug() << "UMLListView::childObjectAdded(" << obj->getName() + << ", type " << ot << "): parent " << parent->getName() + << " does not yet exist, creating it now." << endl; + parentItem = new UMLListViewItem(m_lv, parent->getName(), + convert_OT_LVT(parent->getBaseType()), + parent); + } UMLClassifierListItem *child = static_cast<UMLClassifierListItem*>(obj); QString text = child->toString(Uml::st_SigNoScope); UMLListViewItem *newItem = new UMLListViewItem(parentItem, text,
Have you tried opening the original file again? I just tried rebuilding after svn up (using 3.5 branch). Now it doesn't open a "new class" dialog but a question "is Qt a Namespace or a Class?" And after I say "Namespace" (which if you ask me, is a dumb question considering that everyone reading this message KNOWS that Qt is always a namespace!), instead of crashing like before, I have an empty diagram. Again, file->open lets me open the diagram, but it fails to open from the command line.
This is a hard one to fix, and I don't think I'll be able to fix it in my limited time. However, there is a workaround: Use non command-line loading and save the file with current Umbrello. The renewed format can then be loaded from the command line.
Created attachment 12146 [details] the fix is in don't cry anymore, it's fixed now :-)
> Created an attachment (id=12146) > the fix is in Hmm, I'd say that's a workaround not a fix. Looking at the code of main.cpp and uml.cpp, I'm still baffled that using the command line for passing in the file name could create a different behavior. What does that tell us about robustness and trustworthiness of the code?
true, It's actually only a workaround for *this* bug (which means that on those older files, it will behave itself), but it's a fix for another bug (that is, that i think umbrello should know that Qt is a namespace). If this bug crops up from other old .uml files which contain namespaces used in a certain way, then umbrello *might* pop up that dialog again, which might interfere with the loading process, and I plan to take a closer look at it myself, since I am interested in that part of the code. But the bug is only reproducible on files created with an older version of umbrello, importing classes from an older version of Qt, and perhaps now that both versions are not really "current" it will be very difficult to reproduce. In fact, it is possible that it is only due to the change in file formats. I just don't like that dialog popping up at me asking me obvious questions. On 9 Aug 2005 05:45:42 -0000, Oliver Kellogg <okellogg@users.sourceforge.net> wrote: [bugs.kde.org quoted mail] true, It's actually only a workaround for *this* bug (which means that on those older files, it will behave itself), but it's a fix for another bug (that is, that i think umbrello should know that Qt is a namespace). If this bug crops up from other old .uml files which contain namespaces used in a certain way, then umbrello *might* pop up that dialog again, which might interfere with the loading process, and I plan to take a closer look at it myself, since I am interested in that part of the code.<br> <br> But the bug is only reproducible on files created with an older version of umbrello, importing classes from an older version of Qt, and perhaps now that both versions are not really "current" it will be very difficult to reproduce. In fact, it is possible that it is only due to the change in file formats.<br> <br> I just don't like that dialog popping up at me asking me obvious questions.<br> <br> <br> <br> <div><span class="gmail_quote">On 9 Aug 2005 05:45:42 -0000, <b class="gmail_sendername">Oliver Kellogg</b> <<a href="mailto:okellogg@users.sourceforge.net">okellogg@users.sourceforge.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> ------- You are receiving this mail because: -------<br>You reported the bug, or are watching the reporter.<br><br><a href="http://bugs.kde.org/show_bug.cgi?id=110216">http://bugs.kde.org/show_bug.cgi?id=110216</a><br><br> <br><br><br>------- Additional Comments From okellogg users sourceforge net 2005-08-09 07:45 -------<br>> Created an attachment (id=12146)<br> --> (<a href="http://bugs.kde.org/attachment.cgi?id=12146&action=view"> http://bugs.kde.org/attachment.cgi?id=12146&action=view</a>)<br>> the fix is in<br><br>Hmm, I'd say that's a workaround not a fix.<br>Looking at the code of main.cpp and uml.cpp, I'm still baffled that using the command line for passing in the file name could create a different behavior.<br>What does that tell us about robustness and trustworthiness of the code?<br></blockquote></div><br>
SVN commit 444218 by okellogg: CCBUG:110216 - createUMLObject(): Apply attachment (id=12146) From Alan Ezust > I just don't like that dialog popping up at me asking me obvious questions. M +14 -2 classimport.cpp --- branches/KDE/3.5/kdesdk/umbrello/umbrello/classimport.cpp #444217:444218 @@ -12,13 +12,15 @@ // qt/kde includes #include <qmap.h> #include <qregexp.h> -//#include <kapplication.h> +#include <kapplication.h> #include <kmessagebox.h> #include <kdebug.h> #include <klocale.h> // app includes #include "uml.h" #include "umldoc.h" +#include "umllistview.h" +#include "umllistviewitem.h" #include "umlobject.h" #include "docwindow.h" #include "package.h" @@ -132,13 +134,21 @@ parentPkg = static_cast<UMLPackage*>(o); continue; } - int wantNamespace = KMessageBox::questionYesNo(NULL, + int wantNamespace = 1; + /* We know std and Qt are always a namespaces */ + if (scopeName != "std" && scopeName != "Qt") { + wantNamespace = KMessageBox::questionYesNo(NULL, i18n("Is the scope %1 a namespace or a class?").arg(scopeName), i18n("C++ Import Requests Your Help"), i18n("Namespace"), i18n("Class")); + } Uml::Object_Type ot = (wantNamespace == KMessageBox::Yes ? Uml::ot_Package : Uml::ot_Class); o = umldoc->createUMLObject(ot, scopeName, parentPkg); + kapp->processEvents(); parentPkg = static_cast<UMLPackage*>(o); + UMLListView *listView = UMLApp::app()->getListView(); + UMLListViewItem *lvitem = listView->findUMLObject(o); + listView->setCurrentItem(lvitem); } // All scope qualified datatypes live in the global scope. ms_putAtGlobalScope = true; @@ -148,6 +158,7 @@ t = Uml::ot_Class; origType = umldoc->createUMLObject(t, typeName, parentPkg); ms_newUMLObjectWasCreated = true; + kapp->processEvents(); } if (isConst || isPointer || isRef) { // Create the full given type (including adornments.) @@ -156,6 +167,7 @@ if (ms_putAtGlobalScope) parentPkg = NULL; o = umldoc->createUMLObject(Uml::ot_Datatype, name, parentPkg); + kapp->processEvents(); UMLDatatype *dt = static_cast<UMLDatatype*>(o); UMLClassifier *c = dynamic_cast<UMLClassifier*>(origType); if (c)
I've experienced very similar behaviour, but I'm working with a file created in v.1.5.0. I open umbrello from the command line, with no arguments. It opens my last file and begins asking to name classes. Then then it crashes with a SIGSEGV: ---------------------------------------------------- (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) `shared object read from target memory' has disappeared; keeping its symbols. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1208817984 (LWP 3965)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [KCrash handler] #4 0x00000000 in ?? () #5 0x0811a6e2 in UMLClassifier::resolveRef () #6 0x0817a0c8 in UMLPackage::resolveRef () #7 0x0817a0c8 in UMLPackage::resolveRef () #8 0x0817a0c8 in UMLPackage::resolveRef () #9 0x0817a0c8 in UMLPackage::resolveRef () #10 0x08199a91 in UMLDoc::resolveTypes () #11 0x081a89b7 in UMLDoc::loadExtensionsFromXMI () #12 0x081a9337 in UMLDoc::loadFromXMI () #13 0x081a0d82 in UMLDoc::openDocument () #14 0x0818d8d3 in UMLApp::openDocumentFile () #15 0x08164b6e in main () --------------------------------------------------------------------
Created attachment 14540 [details] File umbrello tries to open Per my comment above, I have the same problem in umbrello v1.5 using a file created in 1.5
I upgraded to v1.5.1 but received the same result.
Attachment 14540 [details] loads fine with branches/KDE/3.5/kdesdk/umbrello r611560.