locked
Line numbering is wrong in native C++ Unit tests RRS feed

  • Question

  • Our team has been running into an issue with Native C++ unit tests in Visual Studio 2012.  When an Assert fails, the line numbers are incorrect in the stack trace.  This specifically happens when the stack trace has multiple functions.

    Here is a simple example, run in a default Native C++ Unit Test project with no settings changed:

    1      #include "stdafx.h"

    2      #include "CppUnitTest.h"

    3

    4      using namespace Microsoft::VisualStudio::CppUnitTestFramework;

    5

    6      namespace UnitTest1

    7      {            

    8             TEST_CLASS(UnitTest1)

    9             {

    10            public:

    11           

    12                   TEST_METHOD(TestMethod1)

    13                   {

    14                          function1();

    15

    16                          function2();

    17                   }

    18

    19                   void function1()

    20                   {

    21                          function2();

    22                   }

    23                   void function2()

    24                   {

    25                          Assert::AreEqual(1,0);

    26                   }

    27            };

    28     }

    And the stack trace that follows:

    Result Message:               Assert failed. Expected:<1> Actual:<0>

    Result StackTrace:          

    at UnitTest1::UnitTest1::function2() in c:\users\edegraff\documents\visual studio 2012\projects\unittest1\unittest1\unittest1.cpp:line 25

                    at UnitTest1::UnitTest1::function1() in c:\users\edegraff\documents\visual studio 2012\projects\unittest1\unittest1\unittest1.cpp:line 22

                    at UnitTest1::UnitTest1::TestMethod1() in c:\users\edegraff\documents\visual studio 2012\projects\unittest1\unittest1\unittest1.cpp:line 16

    While the first line number (26) is correct, the next two are wrong.  Line 22 should be line 21, and line 16 should line 14.  This consistently happens whenever a separate function is called.

    Upgrading to VS2013 yields the same problem. We have been unable to find anyone else with the same issue, any help would be appreciated.

    Monday, April 14, 2014 9:38 PM

Answers

  • The debugger points you to the beginning of the next statement after the one currently executing in that stack frame; hence the line number appears to be too large.

    This behavior is correct and consistent with the behavior of the debugger if it encounters a break point:
    It will stop at the break point at the desired line. But as soon as you step into an expression down the stack frames, that line is executing and the pointer for that stack frame is set to the next statement, which usually is found on the next line.

    Cross check: Duplicate all calls like this: "function1(); function1();" and "function2(); function2();". Now you'll find the expected line numbers in your call stack.

    Monday, April 14, 2014 10:17 PM