Bugzilla – Full Text Bug Listing
| Summary: | Strange profilename for applied stereotype in .uml file (crash reason?) | ||
|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | Toni Siljamäki <toni.siljamaki> |
| Component: | Core | Assignee: | Christian Damus <give.a.damus> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | cletavernier, give.a.damus, papyrus-bugs, rschnekenburger, sebastien.gerard |
| Version: | 1.0.1 | ||
| Target Milestone: | SR2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | bbi deploy | ||
| Bug Depends on: | 408491 | ||
| Bug Blocks: | 436666, 458036, 458197 | ||
| Attachments: | |||
|
Description
Toni Siljamäki
NOTE: I have 12 projects/models in our NWA product workspace, where some model.uml files get a _1 suffix when adding a new function, others don't. I need some additional input / RCA from CEA to analyze this further. (In reply to Toni Siljamäki from comment #0) > > My questions here are: > * What does the _1 suffix in the profilename mean? This is not a profile name, but an XML namespace prefix. It is totally arbitrary but must be uniquely mapped to a namespace URI within a given XML document. By default, EMF uses the 'nsPrefix' attribute of the EPackage as the prefix in the XML (Profiles generate an EPackage with the nsPrefix set to the profile name, hence the similarity) but will, when serializing more than one package having the same 'nsPrefix', distinguish them automatically using _1, _2, etc. suffixes. The nsPrefix is purely an XML thing and has no bearing on the actual UML model/profile semantics. > * Is there a risk that the model will crash later as a result of the _1 ? No. This is purely an XML serialization thing. > * Where does it come from? From EMF's XML serialization infrastructure. > * Why is it put there? To distinguish one EPackage having nsPrefix="Profile" from another EPackage also having nsPrefix="Profile". > * What is the logic behind it? As described above. > * Does it have support in some Eclipse / OMG standard ? In the W3C XML Schema 1.0 standard. > * Which Papyrus code have been executed and what decisions have Papyrus made > along its execution path to make it decide to place _1 there ? None. This is entirely in EMF. > * ...which then can explain this ? > * Why not _2 ? Because there are only two EPackages having nsPrefix="Profile", not three. Add another Profile named "Profile" and you'll see the Profile_2 prefix on its stereotype-application elements. Just to be clear, if there is any bug, it is not caused by the particular XML namespace prefixes used in the serialized form of the model. In reviewing the other profile-related bugs, it seems to me most likely that what has happened here is that the incomplete "profile switch" feature of bug 408491 has left a profile namespace orphaned (no longer managed by a profile application). When the application of the NWAProfile was switch from one copy of the profile to another, both copies naturally have the same NWAProfile name (and hence EPackage nsPrefix), but because the stereotype instances from the old NWAProfile schema remained, any new stereotype instances created from the "new" (switched to) copy of the NWAProfile use the prefix NWAProfile_1 to distinguish them from the left-overs of the old profile. Fixing/completing bug 408491 will make this problem go away. No profile switching from tool X to Papyrus going on here. Sudden _1 suffix happened within the same model.uml file for the same version of a profile for a brand new DSL. Model crashes happen, so RCA is required. (In reply to Christian W. Damus from comment #2) > (In reply to Toni Siljamäki from comment #0) > > > > My questions here are: > > * What does the _1 suffix in the profilename mean? > > This is not a profile name, but an XML namespace prefix. It is totally > arbitrary but must be uniquely mapped to a namespace URI within a given XML > document. Exactly my point! (as you can see in the screenshot) profilename, namespace, whatever: It's the logical name of the profile within the scope for which this name is defined. The screenshot displays 2 names within the same file: With and without _1 suffix for the logical profile name. Papyrus models are crashing. (In reply to Toni Siljamäki from comment #5) > No profile switching from tool X to Papyrus going on here. > Sudden _1 suffix happened within the same model.uml file for the > same version of a profile for a brand new DSL. OK, but UML2 always deletes all stereotype applications defined by a profile when that profile is in applied, so something else must be happening. Are you migrating the profile from one version to another version (of the same profile) that has removed stereotypes or made other incompatible changes? This could possibly cause stereotype applications from the previous version to linger. But even so, they should be harmless, invisible to the tool. > Model crashes happen, so RCA is required. What does "crash" mean? Please be specific about what the symptoms are. Does the JVM process literally crash? (In reply to Christian W. Damus from comment #7) > (In reply to Toni Siljamäki from comment #5) > > No profile switching from tool X to Papyrus going on here. > > Sudden _1 suffix happened within the same model.uml file for the > > same version of a profile for a brand new DSL. > > OK, but UML2 always deletes all stereotype applications defined by a profile > when that profile is in applied, so something else must be happening. Do you mean "...when that profile is unapplied" (removed) ? That's exactly what I have seen does NOT happen in Papyrus, hence Bug 431953. I have also seen stereotypes being left in the .uml file after deleting the element to which the stereotype was applied, but I didn't have the time to report it at the time. But I'm doing it now in Bug 431953. Some other bug may have caused an NPE which aborted the deletion of the stereotype, I cannot tell, but the main problem is that we end up with garbage in the model file which needs to be scanned and fixed by Papyrus, just as Ronan clarifies, so 1) and 2) in Bug 431953 is required. > Are you migrating the profile from one version to another version (of the > same profile) that has removed stereotypes or made other incompatible > changes? This could possibly cause stereotype applications from the > previous version to linger. But even so, they should be harmless, invisible > to the tool. Nope. The profile got finalized 3 weeks ago. I'm just adding a new element to the model, and suddenly I save this new NWAProfile_1 name. The file actually also has two garbage stereotype apps for a stereotype which was removed long time ago. That's an example why this scanning and removal of garbage is needed. (also to prevent garbage memory costs) Attached screenshot shows garbage stereotypes. > > Model crashes happen, so RCA is required. > > What does "crash" mean? Please be specific about what the symptoms are. > Does the JVM process literally crash? As explained in comment 1: I deleted old versions of the profile, I tried it in two different ways, but each time I tried to remove any old profile version for this to-the-latest-profile-version-migrated-model ALL the applied stereotypes vanished. ...but they were still present in the .uml file. (?) Since this DSL is based on those stereotypes I call this a model crash. Created attachment 241602 [details]
Screenshot of garbage and strange _1 name suffix
(In reply to Toni Siljamäki from comment #8) > (In reply to Christian W. Damus from comment #7) > > (In reply to Toni Siljamäki from comment #5) > > > No profile switching from tool X to Papyrus going on here. > > > Sudden _1 suffix happened within the same model.uml file for the > > > same version of a profile for a brand new DSL. > > > > OK, but UML2 always deletes all stereotype applications defined by a profile > > when that profile is in applied, so something else must be happening. > > Do you mean "...when that profile is unapplied" (removed) ? Yes, sorry. That's my phone auto-correcting the word "unapplied". :-) > That's exactly what I have seen does NOT happen in Papyrus, hence Bug 431953. > I have also seen stereotypes being left in the .uml file after deleting the > element to which the stereotype was applied, but I didn't have the time to > report it at the time. But I'm doing it now in Bug 431953. Ah, OK. Are these stereotype applications perhaps in a controlled resource that was not loaded at the time the profile was unapplied? > Some other bug may have caused an NPE which aborted the deletion of the > stereotype, I cannot tell, but the main problem is that we end up with > garbage in the model file which needs to be scanned and fixed by Papyrus, > just as Ronan clarifies, so 1) and 2) in Bug 431953 is required. Yes, exceptions can indeed interrupt these kinds of operations. I agree that the Model Repair function should be extended to include clean-up of dangling stereotype applications. This should be quite feasible, but it will take some thought how best to present it to the user so that he can make useful and safe decisions. > > Are you migrating the profile from one version to another version (of the > > same profile) that has removed stereotypes or made other incompatible > > changes? This could possibly cause stereotype applications from the > > previous version to linger. But even so, they should be harmless, invisible > > to the tool. > > Nope. The profile got finalized 3 weeks ago. I'm just adding a new element > to the model, and suddenly I save this new NWAProfile_1 name. Interesting. The only way the profile should be able to introduce a new namespace is if the ProfileApplication loses track of the old namespace. There must be two different EPackages involved here that are definitions of the same profile. Can you paste the namespace declarations and schema locations for the NWAProfile and NWAProfile_1 namespaces from the root element of the XML? I may be able to infer what happened from those. > The file actually also has two garbage stereotype apps for a stereotype > which was removed long time ago. That's an example why this scanning > and removal of garbage is needed. (also to prevent garbage memory costs) Yes, it looks like they are missing their base_Xyz extension ends, which suggests that they were unapplied from their base elements? > Ah, OK. Are these stereotype applications perhaps in a controlled resource > that was not loaded at the time the profile was unapplied? We are not using fragments yet. (see Bug 394887) > Yes, exceptions can indeed interrupt these kinds of operations. I agree > that the Model Repair function should be extended to include clean-up of > dangling stereotype applications. This should be quite feasible, but it > will take some thought how best to present it to the user so that he can > make useful and safe decisions. Check with Ronan for advice. He has the most complex use cases. > > > Are you migrating the profile from one version to another version (of the > > > same profile) that has removed stereotypes or made other incompatible > > > changes? This could possibly cause stereotype applications from the > > > previous version to linger. But even so, they should be harmless, invisible > > > to the tool. > > > > Nope. The profile got finalized 3 weeks ago. I'm just adding a new element > > to the model, and suddenly I save this new NWAProfile_1 name. > > Interesting. The only way the profile should be able to introduce a new > namespace is if the ProfileApplication loses track of the old namespace. > There must be two different EPackages involved here that are definitions of > the same profile. Can you paste the namespace declarations and schema > locations for the NWAProfile and NWAProfile_1 namespaces from the root > element of the XML? I may be able to infer what happened from those. I will try to isolate a reproducible test case. I may take time, and I may not succeed. Best thing would have been if you sat right next to my screen. (check with FB) This is way too low bandwidth... > > The file actually also has two garbage stereotype apps for a stereotype > > which was removed long time ago. That's an example why this scanning > > and removal of garbage is needed. (also to prevent garbage memory costs) > > Yes, it looks like they are missing their base_Xyz extension ends, which > suggests that they were unapplied from their base elements? Don't know/remember. Our NWA DSL was still under development at the time. They are in there, that's the thing. (In reply to Toni Siljamäki from comment #11) > > > > Interesting. The only way the profile should be able to introduce a new > > namespace is if the ProfileApplication loses track of the old namespace. > > There must be two different EPackages involved here that are definitions of > > the same profile. Can you paste the namespace declarations and schema > > locations for the NWAProfile and NWAProfile_1 namespaces from the root > > element of the XML? I may be able to infer what happened from those. > > I will try to isolate a reproducible test case. > I may take time, and I may not succeed. > Best thing would have been if you sat right next to my screen. (check with > FB) > This is way too low bandwidth... OK, but you already provided some screenshots of the XML from your corrupted model. What I am asking for is essentially a screenshot (or copy/paste) from the top of the file, the root element's beginning tag. <?xml version="1.0" encoding="UTF-8"?> <xmi:XMI xmi:version="20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:NWAProfile="http:///schemas/NWAProfile/_kI1AoKWAEeOqXNVkJgWvxg/34" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:uml="http://www.eclipse.org/uml2/5.0.0/UML" xsi:schemaLocation="http:///schemas/NWAProfile/_kI1AoKWAEeOqXNVkJgWvxg/34 pathmap://NWAPROFILE/NWAProfile.profile.uml#_kJBN4KWAEeOqXNVkJgWvxg"> <uml:Model xmi:id="_HLJBMGfmEeOBhMx-wLHzcQ" name="FixedAccess"> Here is one from another model in the same workspace for which this NWAProfile_1 does NOT happen when adding a new element to the model. <?xml version="1.0" encoding="UTF-8"?> <xmi:XMI xmi:version="20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:NWAProfile="http:///schemas/NWAProfile/_xK5gMLUgEeOZ5uSnKomcRw/36" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:uml="http://www.eclipse.org/uml2/5.0.0/UML" xsi:schemaLocation="http:///schemas/NWAProfile/_xK5gMLUgEeOZ5uSnKomcRw/36 pathmap://NWAPROFILE/NWAProfile.profile.uml#_xK5gMbUgEeOZ5uSnKomcRw"> <uml:Model xmi:id="_Sk_1YGfmEeOBhMx-wLHzcQ" name="MediaServices"> (In reply to Toni Siljamäki from comment #13) Thanks, Toni. I don't see a namespace declaration for NWAProfile_1 namespace, which would definitely be a problem if there are elements that use this prefix! This should only happen if EMF doesn't know the EPackage that defines the corresponding schema, which would happen if you load the model without the profile available to provide that schema and then save again. But, even in this case, EMF would record all of the content from that unresolved namespace along with its namespace URI in order to write it back again on save exactly as it was. Under the covers, EMF creates a fake EPackage to load unresolved-schema content. So, if that's not working, then something is very broken in EMF. But this capability is known not to be broken, so I'm a bit at a loss to explain what is happening without a reproducible test case ... Created attachment 241606 [details]
Screenshot of strange applied-profile definition inconsistency
I think I stubled onto the problem, but it's still a
#&%¤#& bug that happened at some point.
It appears that two different versions of the same profile
is "applied" simultaneously. I'm confused. :(
When did it happen? Why did it happen? In how many models has/will it happen? (In reply to Toni Siljamäki from comment #16) > Created attachment 241606 [details] > Screenshot of strange applied-profile definition inconsistency This screenshot appears to show only a single version of the NWAProfile. (?) > I think I stubled onto the problem, but it's still a > #&%¤#& bug that happened at some point. > > It appears that two different versions of the same profile > is "applied" simultaneously. I'm confused. :( That would certainly cause the two similar namespaces to appear in the XML. Perhaps different versions of the profile are applied to different packages in the model? Created attachment 241607 [details]
Project with profile and model
The screenshot shows the version referred to in the header of the model file.
The Papyrus UI shows the latest version.
The PW is sent to Camille.
The model comes from a live demo at our Archtecture Summit last week,
but it was created some time ago.
As you can see the models in Comment 13 and 14 are referring to different versions of the same profile, but when looking at it in the Papyrus UI they both refer to the latest version. Would it be possible that a tool tries to load a profile in the wrong resource set, then apply this profile to Papyrus? Would two in-memory instances of the same profile, applied on the same model, cause this kind of trouble? (Duplicate namespace) My best guess is that something (NPE) caused the update of the profile for this model to crash/abort, leaving the model in a half-way updated state. But it is a bit strange, since I'm quite sure the model/profile has been updated in several steps between version 0.3.5 and 0.4.1 of the profile. The problem exist in more than one model. (In reply to comment #19) > Created attachment 241607 [details] > Project with profile and model > > The screenshot shows the version referred to in the header of the model file. > The Papyrus UI shows the latest version. Thanks, Toni, but the attached model only has one XML namespace for the profile. There is no *_1 namespace. I'll be back... (shortly) Created attachment 241615 [details]
Stripped NWA plugin without profile
Just tested the below on the model I just sent:
1) Copy the profile to this plugin and install it
2) Rename the FixedAccess\nwa_style\nwa_stylesheet.css
4) Open the FixedAccess model
5) Add a component to the diagram
6) Apply NWAComponent to it
7) Check at the end of the FixedAccess.uml file:
<NWAProfile_1:NWAComponent xmi:id=...
Have a nice weekend/trip.
I'm using Papyrus version 1.0.0.v201403272326 Thanks, Toni. With this, I can reproduce the symptoms. The problem is that the model that you had previously attached had, at some point, been migrated from version 34 to version 36 of the profile. Probably this was initiated by the dialog that automatically pops up on opening the model, prompting to migrate the profile application. Without do anything to the model, I can see that the schema for the existing profile definitions is the 34 version but the profile-application element references the 36 version. At the point of profile migration, the UML2 API *should* have rebuilt all of the existing stereotype applications as instances of the 36 version stereotypes. But, some exception intervened to prevent that. This is what we need to track down now with steps to reproduce: what kind of listener or EMF adapter bombed the PackageOperations::applyProfile(...) method in between updating the profile application and rebuilding the stereotype instances? If you have a workspace log file covering the time when this profile migration was attempted, that could help a lot (assuming it records the exception in question). Delete the FixedAccess model and import it again. That one has xsi:schemaLocation="http:///schemas/NWAProfile/_kI1AoKWAEeOqXNVkJgWvxg/34 in it, so you should be able to repeat the test. Then repeat 2)-7) below, which worked for me. I usually delete all .log files because I do not want to, perhaps accidently, display those errors to potential users. :) The initial part of the scanning/warning for stereotype garbage e.g. when loading a model should check that the applied profile information is consistent throughout the model. When the bug happens you get a warning about it and you know thet somewhere in the .log files there is some information you need. (In reply to Toni Siljamäki from comment #28) Hi, Toni, The model already declares the http:///schemas/NWAProfile/_kI1AoKWAEeOqXNVkJgWvxg/34 schema before doing anything at all, with a profile application that references the http:///schemas/NWAProfile/_xK5gMLUgEeOZ5uSnKomcRw/36 schema. So, the corruption happened before you packaged it to attach to this bugzilla. That's why we need the log file to see whether it records the exception that bombed the profile migration. As I mentioned, I always delete all .log files before showing of providing anything to anyone, especially to potential users. There are no traces left. All bursts and megabytes of errors in these logs are quite annoying. I know that it happened before I reported this bugzilla, and it happened after the 0.3.5 release of the NWAProfile (version 34) the 6th of March the week before I went to CEA to finalize the NWA requirements. The subsequent 0.4.0 release of the profile was on March 26th, and I have updated using nightly's during that period to test new features and bug fixes, walking extra miles (light years) to prepare for the grand launch of NWA modeling in Papyrus at our Architecture Summit the 27th-28th. I made several updates on the 11th, 12th, 18th, 19th, 24th, 25th, 26th and finally late night the 27th (or early) to finally get an update that worked. What happened after 0.3.5 the 6th is that we got a reasonably working NWA update in the M6 release which I installed the 12th and I tested it during the whole weekend preparing for the summit, all working just fine. All I was waiting for was a fix for the "out of handles" bugs. The 17th three "big features" was pushed to master and my problems began after the nightly update the 18th: new bugs and things stopped working. The next 0.4.0 and latest 0.4.1 release of the NWAProfile is from March the 26th, the last thing I did while preparing for the summit, which is when this particular bug appeared. My only advice is to examine (RCA) what happened between M6 March 12th and the features pushed the 17th. I believe the failing 0.4.0 and 0.4.1 updates of the NWAProfile is a consequence of after-M6 activities. I have not had any reason to update the NWAProfile since then, so I do not know if the problems introduced the 17th have been fixed. Maybe you can check that by making a dummy-update of the NWAProfile ? I'm quite sure that the problem described by this bug has been solved by the new "cleaning" function, detecting if multiple versions are applied, which I have verified for Bug 408491. I just noticed that I can close this one myself, so I close it. :) The PW protected attachment in Bug 436666 can be used for testing. https://bugs.eclipse.org/bugs/attachment.cgi?id=250095 As we found out, when discussing this bug, was that the reason for the _1 suffix in the profile name, in this case NWAProfile_1, was that two versions of the same profile was applied simultaneously. After the profile version upgrade of the model attached to Bug 436666, = after slide 4 in the ProfileUpgrade test case, both versions of the profile are applied to the model, the old NWAProfile (47) and new NWAProfile_1 (50). Just noticed that this problem still exists, so this bug has not been solved. After a profile version upgrade of a model, only one version of the profile should be applied to the model = the version being upgraded to. The model and profile versions attached to Bug 436666 can be used for testing and verification that only the latest profile version is applied after upgrade. Repairing stereotypes / cleaning of "zombies" should happen when opening a model, and before the check for profile version upgrade (and after). The fix for bug 436666 comment 47 addresses the scenario described in comment 33 on this bug. The additional namespace occurs because dangling stereotype instances from the previous profile definition remain; they are not affected by profile migration because they are not stereotype applications and are thus invisible to the UML API. Instead, these are now cleaned up by the Stereotype Repair function. Not completely fixed yet. After the profile version upgrade of the model attached to Bug 436666, = after slide 4 in the ProfileUpgrade test case, both versions of the profile are listed in the <profileApplication... See attached screenshot. Created attachment 250254 [details]
Screemshot - Multiple Profile Versions
The listed 0.5.2 version is garbage, after the profile version upgrade.
The annotations shown in attachment 250254 [details] are purely informative, recording the history of profile versions that were applied to the package. The UML API does not recognize them and simply ignores them; they have no effect on the actual profile definition version that is applied (that is provided by the UML annotation, not these Papyrus annotations).
The original problem was the repetition of NWAProfile XML namespaces as "NWAProfile" and "NWAProfile_1". That is fixed by the introduction of dangling stereotype deletion in the repair function. Recurrence of this problem is the only reason why this bugzilla should be reopened.
I don't know why Papyrus adds its own annotations recording a history of applied profile versions (analogous to the history of definitions maintained by UML within the profile history, itself). Perhaps Camille can comment on the use cases that it supports. In any case, if you don't want these annotations to be attached to profile applications or if it should be optional, that would be a separate matter for a new bugzilla request. It is unrelated to the current bugzilla.
> I don't know why Papyrus adds its own annotations recording a history of applied profile versions (analogous to the history of definitions maintained by UML within the profile history, itself). Perhaps Camille can comment on the use cases that it supports.
Papyrus does that? That'd be new. AFAIK the only Papyrus annotation related to profiles is in the Profile Definition (For additional versioning metadata), not on the Profile Application.
I remember a suggestion about having such versionning information on a Profile Application; maybe to display it when the Profile can't be resolved? Although I don't know if the suggestion has been retained or discarded. I also don't remember in which context this had been mentioned. Maybe it wasn't meant to record an "History"; maybe the idea was just to have the current applied version, but the previous EAnnotation wasn't deleted?
I'll look into this tomorrow
> I don't know why Papyrus adds its own annotations recording a history of applied profile versions (analogous to the history of definitions maintained by UML within the profile history, itself). Perhaps Camille can comment on the use cases that it supports. I found the original contribution for this EAnnotation on the ProfileApplication: > 28105: 435995: Profile version numbers missing in the profile-upgrade-popup message https://bugs.eclipse.org/bugs/show_bug.cgi?id=435995 [If83ee0de] > https://git.eclipse.org/r/#/c/28105/ Aha... This profile info might originate from Bug 408316. Users need to "see" properties of the currently applied profile, like its version. Bug 435995 is about temporary info in a popup window while migrating from and to specific versions of a profile. Anyway: The profile application shold only state inormation about the currently applied profile, not a history of previously applied profiles, which can seen as a memory leak. (= not cleaning out garbage) I just tested this in latest Luna nightly, making two upgrades of a profile to a model, after which there also were information about two previously applied profiles in the profile application. (= garbage) I also tested this on a recent Mars nightly, making two upgrades of a profile to a model, and it kept only the current version-info in the profile application. (also tested it when externalizing the profile application) So... This "memory leak" is fixed in Mars, but not in Luna. Camille: Please open a new bug on this for Luna. (In reply to Toni Siljamäki from comment #40) I can confirm that Luna accumulates these version annotations whereas Mars does not. I have raised bug 458643 to address the problem. |