C++ google tests not run

Jesper,

Sorry about that, there's going to be much better diagnostic in the next release of R++.

How are your tests organized? When R++ sees a unit test in a source file, it finds the project that the file is in, looks at the project's "Options->Configuration Properties->Debugging->Local Windows Debugger" property sheet and uses "Command", "Command Arguments" and "Working Directory" properties to start the test process. So this basically means that if tests in your project can be run using Visual Studio's F5, R++ should be able to run them too. Note that for tests in the libraries you'll also have to set these properties for library projects (since R++ does not know which executable project should be used to run them, it will pick them up from the library project itself).

If you could prepare a solution with a repro case for the problem, that would be great.

Thanks!

Test cases only exists in the executable projects. Pressing F5 will run the tests and it is working that way.

The debug properties were set to:

Command: "$(TargetPath)"
Command Arguments: ""
Working Directory: "bin\$(Configuration)"

For some reason the working directory was not compliant with the unit test runner. Changing it to $(ProjectDir)bin\$(Configuration) made it work.

It is however important that the command argument does not include the --gtest_filter option as it will also make the test "Inconclusive".

I can now run all unit tests (1835) in the solution and it works pretty well. I have however seen that it did not detect all unit tests. Pressing the refresh button in the unit test explore view solved that.

One thing more. In one of the test projects when running a unit test in debug mode I get a "Debug assertion failed" dialog. I do not get this box when running the tests using F5. I have attached the dialog.
The box comes about three times, pressing ignore will make the tests proceed and all pass.
Do you have any input on this?

So looks like the culprit was the --gtest_filter command line argument. R++ has to pass its own filter (corresponding to the tests selected to run), and it does that using an environmental variable. I believe command-line flags have higher priority and override the environmental variables, so the tests that R++ expected to be run weren't actually executed.

The working directory problem is unexpected. Relative paths should get expanded using the project location as a base path. Could you please verify that test tests are not being run with working directory set to "bin\$(Configuration)" and that it is not the side effect of the --gtest_filter problem?

Regarding the missing tests problem - if you happen to be able to reproduce this, please report to us how to do it.

It's hard to speculate on the reasons for the assert dialog. You should be able to attach to the test process by clicking the "Retry" button - maybe this will help to figure it out? When tests are run with F5, the test binary runs with the debugger attached, so instead of this dialog the debugger should break on the assert. Could you try starting the tests with Ctrl+F5 and see if the dialog still pops up - that will run them without the debugger attached, just like R++ does.

Actually, I think now I get why the assert fired - perhaps it's the side effect of R++ trying to pass a long gtest_filter variable, which contents exceed the _MAX_ENV limit. Out of curiosity, how many tests are you trying to run at the same time? I've filed https://youtrack.jetbrains.com/issue/RSCPP-15819 and will try to reproduce and fix it in the next release - looks like we need to invoke the test binary several times when the filter string gets too long.

I think it was the working directory that was the problem as changing it from "bin\$(Configuration)" to $(ProjectDir)bin\$(Configuration) made it work.

Making a new VS c++ project will have it set to $(TargetPath), but this had some other issues for us so we changed it, but $(ProjectDir)bin\$(Configuration) seams to work for us. :-)

The test project causing the problem has 1042 tests. When running all tests you could also use "--gtest_filter=*".

As a temperory fix we could deside to split it into multiple test projects

I have another related issue. When I right click a unit test in the Unit test Sessions window and select “debug” an exception is thrown. See image. 

It works when pressing the F5 button. The exception trace from the resharper log prist this:

10:19:12.403 |W| | Member not found. (Exception from HRESULT: 0x80020003 (DISP_E_MEMBERNOTFOUND))

--- EXCEPTION #1/2 [COMException]
Message = “Member not found. (Exception from HRESULT: 0x80020003 (DISP_E_MEMBERNOTFOUND))”
ExceptionPath = Root.InnerException
ClassName = System.Runtime.InteropServices.COMException
HResult = DISP_E_MEMBERNOTFOUND=80020003
Source = mscorlib
StackTraceString = “
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode)
at JetBrains.VsIntegration.Interop.Shim.VsShell.Shell.IVsWindowFrame.GetProperty[TValue](VSFPROPID propid)
at JetBrains.VsIntegration.IDE.Documents.Whidbey.VsDocumentManagerWhidbey.<>c__DisplayClass35.<>c__DisplayClass39.<OnTextManagerRegisterView>b__33()
at JetBrains.Util.Logging.Logger.CatchSilent(Action action)
”

--- Outer ---

--- EXCEPTION #2/2 [LoggerException]
Message = “Member not found. (Exception from HRESULT: 0x80020003 (DISP_E_MEMBERNOTFOUND))”
ExceptionPath = Root
ClassName = JetBrains.Util.LoggerException
InnerException = “Exception #1 at Root.InnerException”
HResult = COR_E_APPLICATION=80131600
StackTraceString = “
at JetBrains.VsIntegration.IDE.Documents.Whidbey.VsDocumentManagerWhidbey.<>c__DisplayClass35.<OnTextManagerRegisterView>b__30()
at JetBrains.Application.IShellLocksEx.ExecuteWithReadLock(IShellLocks thіs, Action F)
at JetBrains.VsIntegration.IDE.Documents.Whidbey.VsDocumentManagerWhidbey.<>c__DisplayClass19.<ExecuteOrQueueOrMergeUnguardedCallbackWithLog>b__18()
at JetBrains.Util.LogCookie.Execute(String comment, Action F)
at JetBrains.VsIntegration.IDE.Documents.Whidbey.VsDocumentManagerWhidbey.<>c__DisplayClass19.<ExecuteOrQueueOrMergeUnguardedCallbackWithLog>b__17()
at JetBrains.Util.Concurrency.UnguardedCallbackMerger.<>c__DisplayClass3.<ExecuteOrQueueOrMerge>b__0()
at JetBrains.Threading.ReentrancyGuard.Execute(String name, Action action)
at JetBrains.Threading.ReentrancyGuard.TryExecute(String name, Action action)
at JetBrains.Threading.ReentrancyGuardEx.ExecuteOrQueue(ReentrancyGuard thіs, Lifetime lifetime, String name, Action F, TaskPriority priority)
at JetBrains.Util.Concurrency.UnguardedCallbackMerger.ExecuteOrQueueOrMerge(Lifetime lifetimeQueue, String name, Action F)
at JetBrains.VsIntegration.IDE.Documents.Whidbey.VsDocumentManagerWhidbey.ExecuteOrQueueOrMergeUnguardedCallbackWithLog(String eventName, VSCOOKIE docCookie, Action action)
at JetBrains.VsIntegration.IDE.Documents.Whidbey.VsDocumentManagerWhidbey.OnTextManagerRegisterView(IVsTextView view)
at JetBrains.DataFlow.Signal`1.NotifySinks(TValue payload)
at JetBrains.DataFlow.Signal`1.Fire(TValue value, Object cookie)
at JetBrains.DataFlow.Signal`1.Fire(TValue value)
at JetBrains.VsIntegration.Interop.Events.TextControls.VsTextManagerEvents.Sink.Microsoft.VisualStudio.TextManager.Interop.IVsTextManagerEvents.OnRegisterView(IVsTextView pView)
at Microsoft.VisualStudio.TextManager.Interop.IVsTextManager.RegisterView(IVsTextView pView, IVsTextBuffer pBuffer)
at Microsoft.VisualStudio.Editor.Implementation.VsTextViewAdapter.Init_InitializeWpfTextView()
at Microsoft.VisualStudio.Editor.Implementation.VsTextViewAdapter.Init_OnActivation()
at Microsoft.VisualStudio.Editor.Implementation.VsTextViewAdapter.QueryStatus(Guid& pguidCmdGroup, UInt32 cCmds, OLECMD[] prgCmds, IntPtr pCmdText)
at Microsoft.VisualStudio.OLE.Interop.IOleCommandTarget.QueryStatus(Guid& pguidCmdGroup, UInt32 cCmds, OLECMD[] prgCmds, IntPtr pCmdText)
at Microsoft.VisualStudio.Platform.WindowManagement.DocumentObjectSite.QueryStatus(Guid& pguidCmdGroup, UInt32 cCmds, OLECMD[] prgCmds, IntPtr pCmdText)
at Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.QueryStatus(Guid& pguidCmdGroup, UInt32 cCmds, OLECMD[] prgCmds, IntPtr pCmdText)
”

10:19:12.841 |W| | Member not found. (Exception from HRESULT: 0x80020003 (DISP_E_MEMBERNOTFOUND))

--- EXCEPTION #1/2 [COMException]
Message = “Member not found. (Exception from HRESULT: 0x80020003 (DISP_E_MEMBERNOTFOUND))”
ExceptionPath = Root.InnerException
ClassName = System.Runtime.InteropServices.COMException
HResult = DISP_E_MEMBERNOTFOUND=80020003
Source = mscorlib
StackTraceString = “
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode)
at JetBrains.VsIntegration.Interop.Shim.VsShell.Shell.IVsWindowFrame.GetProperty[TValue](VSFPROPID propid)
at JetBrains.VsIntegration.IDE.Documents.Whidbey.VsDocumentManagerWhidbey.<>c__DisplayClass35.<>c__DisplayClass39.<OnTextManagerRegisterView>b__33()
at JetBrains.Util.Logging.Logger.CatchSilent(Action action)
”

--- Outer ---

--- EXCEPTION #2/2 [LoggerException]
Message = “Member not found. (Exception from HRESULT: 0x80020003 (DISP_E_MEMBERNOTFOUND))”
ExceptionPath = Root
ClassName = JetBrains.Util.LoggerException
InnerException = “Exception #1 at Root.InnerException”
HResult = COR_E_APPLICATION=80131600
StackTraceString = “
at JetBrains.VsIntegration.IDE.Documents.Whidbey.VsDocumentManagerWhidbey.<>c__DisplayClass35.<OnTextManagerRegisterView>b__30()
at JetBrains.Application.IShellLocksEx.ExecuteWithReadLock(IShellLocks thіs, Action F)
at JetBrains.VsIntegration.IDE.Documents.Whidbey.VsDocumentManagerWhidbey.<>c__DisplayClass19.<ExecuteOrQueueOrMergeUnguardedCallbackWithLog>b__18()
at JetBrains.Util.LogCookie.Execute(String comment, Action F)
at JetBrains.VsIntegration.IDE.Documents.Whidbey.VsDocumentManagerWhidbey.<>c__DisplayClass19.<ExecuteOrQueueOrMergeUnguardedCallbackWithLog>b__17()
at JetBrains.Util.Concurrency.UnguardedCallbackMerger.<>c__DisplayClass3.<ExecuteOrQueueOrMerge>b__0()
at JetBrains.Threading.ReentrancyGuard.Execute(String name, Action action)
at JetBrains.Threading.ReentrancyGuard.TryExecute(String name, Action action)
at JetBrains.Threading.ReentrancyGuardEx.ExecuteOrQueue(ReentrancyGuard thіs, Lifetime lifetime, String name, Action F, TaskPriority priority)
at JetBrains.Util.Concurrency.UnguardedCallbackMerger.ExecuteOrQueueOrMerge(Lifetime lifetimeQueue, String name, Action F)
at JetBrains.VsIntegration.IDE.Documents.Whidbey.VsDocumentManagerWhidbey.ExecuteOrQueueOrMergeUnguardedCallbackWithLog(String eventName, VSCOOKIE docCookie, Action action)
at JetBrains.VsIntegration.IDE.Documents.Whidbey.VsDocumentManagerWhidbey.OnTextManagerRegisterView(IVsTextView view)
at JetBrains.DataFlow.Signal`1.NotifySinks(TValue payload)
at JetBrains.DataFlow.Signal`1.Fire(TValue value, Object cookie)
at JetBrains.DataFlow.Signal`1.Fire(TValue value)
at JetBrains.VsIntegration.Interop.Events.TextControls.VsTextManagerEvents.Sink.Microsoft.VisualStudio.TextManager.Interop.IVsTextManagerEvents.OnRegisterView(IVsTextView pView)
at Microsoft.VisualStudio.TextManager.Interop.IVsTextManager.RegisterView(IVsTextView pView, IVsTextBuffer pBuffer)
at Microsoft.VisualStudio.Editor.Implementation.VsTextViewAdapter.Init_InitializeWpfTextView()
at Microsoft.VisualStudio.Editor.Implementation.VsTextViewAdapter.Init_OnActivation()
at Microsoft.VisualStudio.Editor.Implementation.VsTextViewAdapter.Microsoft.VisualStudio.TextManager.Interop.IVsCompoundAction.OpenCompoundAction(String pszDescription)
”

Jesper,

The exception in the logs most likely has nothing to do with the exception. If you hit the break button, does Visual Studio show you the call stack? What does it look like?

The stacktrace looks a bit strange. The unloaded symbos for vld_x86.dll is visual leak detector.

Sorry, I've got no ideas. I've checked that debugging tests does work with VLD enabled for me. Does this exception still happen if you disable VLD in your project?

Hi,

I have similar issue as mentioned above but my stack trace is not corrupted. It just contains 4 top lines. Single stepping to narrow down the issue ended up on Windows _fsopen() function call usage with valid arguments. It is strange that ReSharper C++ Unit Test Debug mode throws an exception from inside that function while regular Unit Test Run from ReSharper works fine. Moreover debugging from Visual Studio of that test also works fine.

Please help.

Mat

Mateusz,

Could you please attach your stack trace?

If the problem does not reproduce when you're running/debugging just a single test, then it could be the original issue - R++ constructed an excessively long environment variable and various asserts fired on it. If so, please try the latest 10.1 EAP build (available from https://confluence.jetbrains.com/display/ReSharper/ReSharper+10.1+EAP) where this issue should be fixed.

Thanks,

Igor

I tried 10.1 EAP and it did not help. Below is the error and stack trace for the exception:

Mateusz, thanks for the info!

Looks exactly like Jesper's stack trace. To summarize - this happens when you try to debug a single unit test via R++'s test runner. If you start debugging from Visual Studio, then everything works fine. Is the binary x64 or x86? Would the debugger be able to show you the name of the DLL which is being loaded? It should be in the first argument to LdrLoadDll.

We'll try to take a look, but I don't have any good ideas at the moment. If you could somehow minimize the solution so we could reproduce this, it would be really great. Alternatively we could try this on your solution (under an NDA of course).

Thanks!

In my case the binary is x64. Unfortunately I am unable to see the name of the DLL being loaded. If I will be able to reproduce it on some small and fake solution I will let you know.

BTW, it might be worth mentioning that in my case VS solution is being generated by cmake.

Igor, I'm having the "Can't create process" problem but I'm not passing a "--gtest_filter " argument. Any thoughts?

Sandeep, what's the full error message? It should contain the command line used to run the tests. Can you run the test binary from Visual Studio?

"Unit Test Runner failed to run tests

Can't run "C:\...\project_directory\Debugx64\test\test.lib --gtest_list_tests" with working director "C:\...\project_directory": Can't create process."

I can both execute the test binary from Visual Studio and (with the Google Test Adapter extension installed) run the tests using Visual Studio's native test runner.

Sandeep, R++ can only run tests from projects which have an executable as a target at the moment. We'll try to fix that, please vote for https://youtrack.jetbrains.com/issue/RSCPP-17786 to receive updates.

Just to confirm, the solution has an executable target. R++ really doesn't support it?

To run a test, R++ find the project that the file with a test is in, and uses the "Command", "Command Arguments" and "Working Directory" from the "Debugging" property page to execute the test binary. If you set these properties for your library project to point to the actual executable that links with the binary, R++ should be able to run tests from the library.

It looks like I have the same issue as Jesper and Mateusz. I have VS2013 (12.0.40629.00 Update 5) with ReSharper C++ 2016.2.2. Like Mateusz, my solution is generated by CMake.

• Running my unit tests from VS works fine.
• Debugging my unit tests from VS works fine.
• Running my unit tests from ReSharper (all or individual) works fine.
• Debugging my unit tests from ReSharper (all or individual) fails with the following stack trace in VS:

ntdll.dll!LdrpLoadDependentModule()
ntdll.dll!LdrpMapAndSnapDependency()
ntdll.dll!LdrpMapDllWithSectionHandle()
ntdll.dll!LdrpMapDllNtFileName()
ntdll.dll!LdrpMapDllFullPath()
ntdll.dll!LdrpProcessWork()
ntdll.dll!LdrpLoadDllInternal()
ntdll.dll!LdrpLoadDll()
ntdll.dll!LdrLoadDll()

This stack trace is in a thread named "ntdll.dll!DbgUiRemoteBreakin()". I assume this thread is only created when debugging. Please let me know if I can provide any other details from the log that might be helpful.

It would be great if you could share the project where this problem reproduces with us. If not, a minidump might be useful - after the exception please save the dump via "Debug -> Save Dump As... -> Minidump with Heap", compress it, upload to ftp://ftp.intellij.net/.uploads/ and let us know the name of the file. Thanks!