BUG: Strip GUID's corrupts database

[Geert Bellekens]

I found a major bug in EA (7.0.815)
When importing an xmi file that was created using version control and selecting the option "Strip GUID's", the database gets corrupted someway. It crashes EA (windows application error: The instruction at "0x09bacd3d" referenced memory at "0x0000000c". The memory could not be "read".)
After restarting EA the model is no longer accessible, when trying to load the model EA crashes with the same message.
This bug is not related to the repository type. (I reproduced the error on Oracle, Mysql and .eap file)
It does seem to be related to the version control settings. We have Serena Dimensions (PVCS 10) setup as version control system through the scc interface. It is only when the version control is configured that it has this problem. When using a new project, without the version control setup, it imports fine.
I'll submit a bug report for this issue.

[«Midnight»]

Thanks for the warning.

Please tell us what you hear back from Sparx.

[Geert Bellekens]

A workaround to fix your database is to delete the newly created package from t_package.
EA will then open the project without crashing.

[Martin Terreni]

I exported packages with version control (TFS over MSSQL2005) and then imported them stripping GUID and it worked fine.

[Geert Bellekens]

I received response from Sparx Support:

Hello Geert,
 
Thank you for your email reporting the problems you are experiencing with EA's version control functions.


After spending the morning investigating this issue, I have not been able to reproduce the problem.
 
From your email, I understand that the EA model you attached appears to be corrupt, yet it opens without any problem on my machine.  I do not have Serena Dimensions installed on my machine, so I get an error message to the effect that "the SCC Provider can not be found", but then the model opens as I would expect.
 
When I modified your model to connect to TFS for version control in place of Dimensions, (this involved updating values in the Windows registry as well as updating values in your model database) the model loads correctly and I could also import the file "ControlledPackageB.xml" using the "Strip GUIDS" option, without error.
 
I am beginning to think that the problem you are seeing stems from the Dimensions SCC client.
 
When connecting to a third party SCC product, EA loads a DLL that is provided by that third party (in your case it is Serena Dimensions) and then EA calls functions that are implemented by that DLL, to communicate with the version control server.  The functions implemented by the DLL, become part of EA for the purpose of communicating with the server, so any errors arising from the DLL will appear to be coming from EA.
 
 
If you "hide" the Dimensions SCC client from EA, I believe that your "corrupt" model will load without any problem.
 
Please carry out the following steps to confirm whether the Dimensions SCC client is causing this problem.
 
1.  Start the Windows utility "regedit".
2.  Navigate to the registry key
[HKEY_LOCAL_MACHINE\SOFTWARE\SourceCodeControlProvider\InstalledSCCProvi
ders]
3.  Export this key to a temporary file, so that you can easily restore the values, following this test.
4.  Locate the entry "Serena Dimensions" (or similar) and delete it.
 
5.  Now, restart EA (so that it re-reads the registry values) and try again to load your "corrupt" model.  
 
I expect that you will see the following error message,
Printscreen of error: Error while initializing Version Control provider
 
but, after clicking OK, your model will load as expected.  If it does load correctly, then I believe that the problem is related to the Dimensions SCC client and is not related to EA.
 
Double-click on the file where you exported the registry values to restore those values to the registry.
 
 
Please let me know what you find.

I tried the suggested steps:

- delete the registry key for Serena Dimensions
- open my "currupted" project
- It openend without crashing
- re-merged the registry key
- open the "corrupted" project
- EA crashed again

So it does seem to be related to the scc client. I hope they can fix this soon.

[Geert Bellekens]

So the story continues....
Reply from Sparx support:

Hello Geert,

If there is a problem with the SCC client (and it certainly appears that there is), then it is not something that is under control of Sparx Systems.  It is not possible for Sparx Systems to modify in any way, code written by Serena.

You will need to report the problem to Serena.

>
> When connecting to a third party SCC product, EA loads a DLL that is
> provided by that third party (in your case it is Serena Dimensions)
and
> then EA calls functions that are implemented by that DLL, to
> communicate with the version control server.  The functions
implemented
> by the DLL, become part of EA for the purpose of communicating with
the
> server, so any errors arising from the DLL will appear to be coming
from EA.
>

Please feel free to pass on my contact details to them, as I am happy to work with them to resolve this problem.

to which I responded:

I don't think that I agree completely.
Offcourse the Serena dll should never crash like that, I will report the issue to Serena support as well. But on the other hand, I believe there is something wrong with the way EA is handling this import as well.
I did some more tests, each one on a clean model, with Serena version control configured:
- Import the problem xmi file without stripping GUID's -> import worked fine, and the package was recognised as a controlled package in Serena. (key icon on the package)
- Import the problem xmi file with the option strip GUID's -> crash!
- Edited the xmi file and removed the "<UML:TaggedValue tag="packageFlags" value="VCCFG=Dimensions10;CRC=0;"/>" part. Then imported this xmi file with the option strip GUID's -> import worked fine, package not controlled by Serena.

So my question is, what is EA doing differently during the import depending on the option "strip GUID's". I see that there is a CRC part, so I can imagine that this CRC would change if you start changing the GUID's.

This last behaviour was the one I was looking for when I originally encountered this problem, so my immediate problem is solved.

By the way, I also found out that I can fix the broken project by removing the value in the field t_package.PackageFlags for the just created package.

To be continued...

[Geert Bellekens]

Got another reply from Sparx support:

Hello Geert,

Following your last email, I stepped through EA's package import code
and found the reason why the VCCFG value in the PackageFlags is not
being cleared as part of the "stripGUIDs" import process.

This code will be corrected in EA build 817.

This also led to me finding what I believe is causing the Dimensions SCC
client to crash.

===================================================
Please pass on the following information to Serena;

During import of a package, the package had its filename set to NULL,
but its VCCFG value was not cleared and still referenced the Dimensions
configuration.

EA then attempted to refresh the VC status of its controlled packages
and included the package with the empty filename in this query.  EA
created a pathname for this package's XMI file, that consisted of a
folder path, but no file name.  

EA subsequently assembled a list of filenames to pass into the SCC
client's SccQueryInfo function, similar to the example below;


C:\VC_workspace\Dimensions\file1.xml

C:\VC_workspace\Dimensions\file2.xml

C:\VC_workspace\Dimensions\

C:\VC_workspace\Dimensions\file3.xml

Apparently, this has caused the DLL function SccQueryInfo, to crash.

===================================================

[«Midnight»]

Progress...

Note to all: The most recent Sparx response might indicate that we've passed the cutoff for fixes to be included in build 816.

[Geert Bellekens]

Although the fix was promised for build 817 it is already fixed in 816

[«Midnight»]

Although the fix was promised for build 817 it is already fixed in 816

Well, that pays the bulldog as I see it.