3 Replies Latest reply on Mar 14, 2012 2:54 PM by fswehosky

    Problems with 3.5.1116

    Hellblau

      Hello,

       

      I was upgrading from an older version ( 3.0.902.0635 ) on Windows with VS2010 and noticed some problems with a dll I am profiling.

       

      When I profile the dll, which is called by a very thin application, and examine its functions, I am using the event based profile - cycles etc., CodeAnalyst seems to keep the dll file open so i cannot rebuild and rerun the profile as the file cannot be opened for writing anymore. This happens from both CodeAnalyst integrated into VS2010 and the standalone CodeAnalyst application.

       

      I also noticed that I cannot view counter events inside of assembler functions ( I am using yasm ) as these functions are not disassembled correctly anymore in the function view. Most of the time a completely different function is shown for which source is available or the disassembly is spanning a range of 0 bytes of instructions - which is very strange.

       

      I moved back to 3.0.902.0635 but as this is more than a year old its somewhat frustrating, 3.5.1115 showed the same behaviour as 3.5.1116.

       

      Can someone please try to reproduce my problems ?

      I am very interested into knowing if its just me if its something introduced recently in newer CodeAnalyst versions.

        • Re: Problems with 3.5.1116

          Hello Hellblau,

           

          When I profile the dll, which is called by a very thin application, and examine its functions, I am using the event based profile - cycles etc., CodeAnalyst seems to keep the dll file open so i cannot rebuild and rerun the profile as the file cannot be opened for writing anymore. This happens from both CodeAnalyst integrated into VS2010 and the standalone CodeAnalyst application.

          CodeAnalyst opens the actual dll to get the function names and disassembly.  You can use the context menu item Cache module on the module name to save a copy of the module and open that to display the information.

           

          I also noticed that I cannot view counter events inside of assembler functions ( I am using yasm ) as these functions are not disassembled correctly anymore in the function view. Most of the time a completely different function is shown for which source is available or the disassembly is spanning a range of 0 bytes of instructions - which is very strange.

          I'm not sure what you mean by "disassembled correctly anymore".  Do you mean after you rebuilt the dll?  Do you use yasm to build the dll?  Is this a 32-bit or 64-bit module? Can you provide some example code bytes which are not being disassembled correctly?  We are aware of a function size issue which will be fixed in our next release.

           

          I moved back to 3.0.902.0635 but as this is more than a year old its somewhat frustrating, 3.5.1115 showed the same behaviour as 3.5.1116.

           

          Can someone please try to reproduce my problems ?

          I am very interested into knowing if its just me if its something introduced recently in newer CodeAnalyst versions.

          Can you provide a small example for us to help reproduce this?

          Thanks,

          -=Frank

            • Re: Problems with 3.5.1116
              Hellblau

              Thanks, the cache module trick works. However is there a way to force CodeAnalyst to let go of the module so i do not have to restart Visual Studio for rebuilding dll if I forget to cache the module ?

               

              Regarding the unviewable assembler function, I attached a small VS 2010 project that shows that problem as it uses a function implemented in assembler using yasm. For me CodeAnalyst shows the assembler function correctly in the module overview, ie event samples are accounted for it, but it does not show the function disassembly when double clicking the function name and shows a different function instead.

                • Re: Problems with 3.5.1116

                  CodeAnalyst holding the module file open is a bug which will be fixed in the next release, coming real soon now. 

                   

                  Thank you very much for providing an example!  When I built and profiled the release version of catest with a timer-based profile, I got samples in h261_compensate_8x8_filter_sse2, which looks correct.  The function name in the source tab and disassembly seemed to work correctly in the alpha version, which also fixed the module file handle bug.

                   

                  I hope that soon you won't experience any problems with CodeAnalyst and can optimize easily.

                  Thanks,

                  -=Frank