Summary: | Umbrello - Segmentation fault when trying to generate code Java | ||
---|---|---|---|
Product: | [Applications] umbrello | Reporter: | MpMp <agv46> |
Component: | general | Assignee: | Umbrello Development Group <umbrello-devel> |
Status: | RESOLVED FIXED | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 4.8.1 | |
Attachments: |
XMI file of the umbrello project
XMI file, fixed |
Description
MpMp
2010-04-29 11:55:55 UTC
Created attachment 43094 [details]
XMI file of the umbrello project
Created attachment 68805 [details]
XMI file, fixed
On loading your XMI, I see
umbrello(7252) Model_Utils::findUMLObject: findUMLObject: type mismatch for "boolean" (seeking type: "ot_Datatype" , found type: "ot_Class" )
umbrello(7252) Model_Utils::findUMLObject: findUMLObject: type mismatch for "String" (seeking type: "ot_Datatype" , found type: "ot_Class" )
which is true, you have extra classes "String" and "boolean" in the Logical View although these are predefined Java types which should appear in the Datatypes folder.
In the attachment, the extra classes are replaced by the predefined types.
Further, in line 137 you have:
<UML:Generalization discriminator="" visibility="public" isSpecification="false" namespace="Logical View" child="MJy1trKgW4aY" xmi.id="UBaouQwfj4Zn" parent="V41PJPJeavLm" name=""/>
which defines AbstractRisorsa to inherit from Risorsa (doesn't sound right?) and in fact, in the next line:
<UML:Generalization discriminator="" visibility="public" isSpecification="false" namespace="Logical View" child="V41PJPJeavLm" xmi.id="P7m4zwzCGeDu" parent="MJy1trKgW4aY" name=""/>
you have an inheritance in the opposite direction.
The mutual inheritance throws Umbrello off the handle and so I've removed the first one. (Actually I wonder why Umbrello did not disallow its creation.)
SVN commit 1282402 by okellogg: (In reply to comment #1) > [...] > you have an inheritance in the opposite direction. > The mutual inheritance throws Umbrello off the handle and so I've removed > the first one. (Actually I wonder why Umbrello did not disallow its > creation.) It turns out that AssocRules::allowAssociation(Uml::AssociationType, UMLWidget *, UMLWidget *) was being called twice: First in ToolBarStateAssociation::setSecondWidget() (toolbarstateassociation.cpp:226) and again via ToolBarStateAssociation:: addAssociationInViewAndDoc() in UMLView::addAssociation(). At the time of the second call, the AssociationWidget was already created and inserted at its role widgets. Fixed as follows: - In UMLView::addAssociation(), remove the call to AssocRules::allowAssociation() - At ToolBarStateAssociation::addAssociationInViewAndDoc(), change return type to bool (true for success) and test the success at ToolBarStateAssociation::setSecondWidget() - Revert the "#if 0" at the extendedCheck code at assocrules.cpp:170 ff. thus re-enabling the check for illegal mutual associations. M +1 -0 ChangeLog M +0 -33 umbrello/assocrules.cpp M +9 -6 umbrello/toolbarstateassociation.cpp M +1 -1 umbrello/toolbarstateassociation.h M +0 -7 umbrello/umlview.cpp M +25 -6 umbrello/widgets/associationwidget.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1282402 set version-fixed-in from 4.8.1 changelog |