Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 CRITICAL ERROR: VA Rename corrupts source code

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
gbozoki Posted - Feb 06 2013 : 4:40:34 PM
I just ran into a case where VA Refactor->Rename corrupts unrelated source code during the rename operation in VS 2008. This is at least the 4th occasion in the past ~1 year when Rename corrupted source code. There were more when I noticed the problem early and cancelled the Rename dialog before it could cause damage.

This is a mixed solution of ~15 projects: C# and C++ projects. Total number of files is ~1700. I have a C# class, something like:

namespace Some.Name.Space
{
    internal class Parser
    {
        #region ParserState
        private sealed class ParserState
        {
            #region Private members
            ...
            private int m_nPos = -1;
            ...
            #endregion

            #region Public members
            public int Pos
            {
                get { return ( m_nPos ); }
                set { m_nPos = value; }
            }

            ...
            #endregion
        }
        #endregion

        #region Public members
        public ParseResult Parse ( string sInput )
        {
            ParserState oState = new ParserState ( sInput );

            ...
            oState.Pos++;
            ...
        }
        #endregion
    }
}


When I tried to rename the Pos symbol to Position, it did so but when I tried compiling the project, I got errors in another (C++) project in the solution that I didn't touch. I was able to revert the changes to the C++ source because it's a 3rd party project (zLib) and it's not being worked on. I had to manually revert the changes in the C# source code to avoid losing a day's work (and to be able to try to reproduce this).

This is the result list when I try to use Refactor->Rename on the Pos symbol:



Another case that I found (I only used Find References with this):

using System;
using System.Collections.Generic;
using System.Text;

namespace Some.Name.Space
{
    /// <summary>
    /// 
    /// </summary>
    internal class XRange
    {
        #region Private members
        private int m_nPosition;
        private int m_nLength;
        #endregion

        #region Constructor
        /// <summary>
        /// Constructor
        /// </summary>
        public XRange () :
            this ( -1, -1 )
        {
        }

        /// <summary>
        /// Constructor
        /// </summary>
        /// <param name="nPosition"></param>
        /// <param name="nLength"></param>
        public XRange ( int nPosition, int nLength )
        {
            m_nPosition = nPosition;
            m_nLength = nLength;
        }
        #endregion

        #region Public members
        /// <summary>
        /// 
        /// </summary>
        public int Position
        {
            get
            {
                return ( m_nPosition );
            }
            set
            {
                m_nPosition = value;
            }
        }

        /// <summary>
        /// 
        /// </summary>
        public int Length
        {
            get
            {
                return ( m_nLength );
            }
            set
            {
                m_nLength = value;
            }
        }
        #endregion
    }
}


Edit:

When I run Find References for the public Length property, the result list shows 22 matches - only 3 are correct, all others are wrong. Out of the 22 matches, 16 are checked. Matches come from unrelated C++ source / header files in other projects (in the same solution) and from unrelated C# classes in the same project.

I looked through some of the incorrect matches in C++ source - there's a macro defined like:

#define InitializeObjectAttributes(pOA,pName,lAttr,hRoot,pSD) \{ \    ( pOA )->Length = sizeof ( OBJECT_ATTRIBUTES ); \    ( pOA )->RootDirectory = hRoot; \    ( pOA )->Attributes = lAttr; \    ( pOA )->ObjectName = pName; \    ( pOA )->SecurityDescriptor = pSD; \    ( pOA )->SecurityQualityOfService = NULL; \}


This macro triggered several matches in .h and .cpp files. It seems like that almost anything that looks like ...->Length ... triggers a match from C++ code. No files outside the solution have been listed in results.

Although a bunch of unrelated C# files / classes are listed, no unrelated symbol is actually checked in C# code. The incorrect C# matches are strange because things like:

FileInfo oFI = ...;
long lLen = oFI.Length;


triggered '?' (unchecked) matches. The type of oFI is not related to XRange, they just happen to have similarly named properties.

Related problems:
http://forums.wholetomato.com/forum/topic.asp?TOPIC_ID=11026
http://forums.wholetomato.com/forum/topic.asp?TOPIC_ID=10527

--------------------
System info:

VA_X.dll file version 10.7.1925.0 built 2012.12.14
Licensed to:
VA X: ... (1-user license) Support ends 2013.06.18
DevEnv.exe version 9.0.30729.1 Enterprise
msenv.dll version 9.0.30729.1
Font: Courier New 13(Pixels)
Comctl32.dll version 6.10.7601.17514
Windows 7 6.1 Build 7601 Service Pack 1
8 processors (x86-64; WOW64)
Language info: 1252, 0x409

Platform: Win32
Stable Includes:
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\include;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\include;

Other Includes:

Stable Source Directories:
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\mfc;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\mfcm;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\atl;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\crt\\src;
5   L A T E S T    R E P L I E S    (Newest First)
support Posted - Feb 25 2013 : 12:18:11 PM
case=72271 is a duplicate of case=9860 and is fixed in build 1929
feline Posted - Feb 13 2013 : 2:58:42 PM
Thank you, that will help. The problem with Rename updating macro declarations has been fixed internally, and the fix should be in the next build of VA.
gbozoki Posted - Feb 13 2013 : 2:42:05 PM
Feline,

Thanks for your answer. I'm very busy right now so it may take a few days but I'll try to put together a small test project for you.
feline Posted - Feb 07 2013 : 6:06:18 PM
Problem 1 we are aware of an occasional problem where Find References from C# will find references in C++ that it thinks are solid matches, so no question marks. Its hard to reproduce here, but we have found 1 test case, I have added some comments on what you are seeing to it:

case=72085

problem 2, I have put in a bug report for Find References finding the solid match inside the macro definition. That is clearly not helpful:

case=72271

Is there any chance of getting two of the .cs files you are using for testing purposes? The one where the class is declared and one of the files where you got the possible matches. I realise this is often not possible, but if it is possible it would allow me to try and reproduce this effect here.

If possible please submit the files via the form:

http://www.wholetomato.com/support/contact.asp

including this thread ID or URL in the description, so we can match it up.
gbozoki Posted - Feb 06 2013 : 7:16:54 PM
Updated first post with more information.

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000