Bug 110216

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 &quot;current&quot; 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> &lt;<a href="mailto:okellogg@users.sourceforge.net">okellogg@users.sourceforge.net</a>&gt; 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&nbsp;&nbsp;2005-08-09 07:45 -------<br>&gt; Created an attachment (id=12146)<br> --&gt; (<a href="http://bugs.kde.org/attachment.cgi?id=12146&amp;action=view">
http://bugs.kde.org/attachment.cgi?id=12146&amp;action=view</a>)<br>&gt; 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.