I'm a beginner C++ developer working on a quality assurance project utilizing the GoogleTest framework. While creating unit tests, to verify whether solution outputs were within an acceptable range or not, I received the error message of " LINK1104: cannot open file 'C:Users\kfung\Documents\SAM\sam_dev\ssc\build_vs2017\x64\Release\test.exe' ".
It came out of nowhere. I've been working within the SAM\sam_dev branch for quite sometime now, where I have complete access to this. On top of that, this error message came after trying to build my solution. When this message came, I was only changing integer values, so I do not think it really is linked to that action. It wasn't anything major.
The test.exe program works fine and is able to test all of the files within my test explorer. The program works, yet VS17 is unable to locate/use this file.
I've searched throughout stack overflow and google and nothing like my issue has been discussed. The error has came out of nowhere with nothing really to prompt it.
I've tried "resetting" my development branch on Gitbash using the commands "checkout -- . ", where I should have reverted my project to it's workings state before this occurred. This did not effect my solution where the error keeps occurring.
What should I do?
Related
newbie here. I am following along this SFML flappy bird tutorial. I am currently stuck at this portion of stage creation where a "Splash State" (or logo loading screen) is made. The code of which is exactly the same as what is shown here.
I am using xcode 10.1.
The project builds. But when I tried running it, it crashes and I am greeted with the following:
Failed to load image "Resouces/res/Splash Background.png". Reason: Unable to open file
libc++abi.dylib: terminating with uncaught exception of type std::out_of_range: map::at: key not found
(lldb)"
If I understand it correctly, it's saying it cannot perform the action of loading the image at the aforementioned path because it is not able to open "libc++abi.dylib". And now the program is being terminated. (please help me understand this problem better by either confirming or correcting me here).
When I tried looking for "libc++abi.dylib", it is missing. Instead, I can only find "libc++abi.td".
This thread says to add that under Link Binary With Libraries. That did not produce any result.
The tutorial shows that the code runs and a "Splash State" or logo screen is expected to appear. Instead my program crashes and I am greeted with the aforementioned error.
I was wondering if anyone else ran into similar issues?
It's solved. It is made by a typo on my end... sorry.
I'll try my best to explain it here for those of you who may have the same issues:
The game asset is governed by a map, which is a private member variable of a "AssetManager" class. The typo is at the file path. Because of this, the map never inserted the key since the file path isn't valid.
When the map is later accessed, it would be out of range since nothing ever got inserted (since the asset did not load).
Basically, the error of not being to open "libc++abi.dylib" is caused by the map being out of range.
I'm using Rcpp to run C++ code using RGui (version 3.4.1) as a user interface. Quite often I make changes to the C++ code which compile correctly but cause errors (e.g. searching beyond the end of an array) when I run the relevant program in RGui, causing RGui to crash. This is aggravating because I have to re-open RGui, re-open my R script (sometimes with unsaved changes lost), set the working directory again, etc. before I can re-compile the C++ code and run the program in such a way as to find the problem or test amendments. Sometimes it promptly crashes again because I haven't fixed or bypassed the problem.
Is there some way to change the way Rcpp runs such that RGui returns an error message instead of crashing in these sorts of situations?
Briefly:
It is spelled Rcpp. Capital R, lowercase cpp.
Yes, don't have bugs :)
In general, 2. is the only viable answer. If you need a managed language, use R.
If the code takes your environment down, test outside the environment. Seriously. That is for example why I (co-)wrote littler and test "raw code" on the command-line: it can only take the command-line app down.
We do have a feature in eg RcppArmadillo to test for "out of bounds" vector access: use x.at(i,j) which will warn. See http://arma.sourceforge.net/docs.html#element_access
I don't actually know of a way to prevent this apart from more careful programming, and saving before execution. But having done this a few times I have discovered a way to get back at unsaved changes, (at least in windows).
When you get the pop-up that tells you to restart R, you don't do it. You open up task manager and right-click on the process and select 'Create Dump File'. Find this file in explorer and open it with some text editor.
They are very big, and full of all sorts of stuff, but if you use find function to search for some string you know to be in your script, then you can find all the unsaved work. You can then copy and paste this into another file to save.
If you use R-studio instead of R-GUI, it usually manages to look after your unsaved work better.
I've been trying to build chromium on Windows 10, but I am getting weird errors on runtime, which appear to be caused by that pattern:
void CheckFreeLibrary(HMODULE module) {
BOOL result = ::FreeLibrary(module);
DCHECK(result);
}
The first errors are displayed after a few seconds after Chromium is started. Here's what it says:
[5904:9192:0726/025753:FATAL:module_list.cc(18)] Check failed: result.
Backtrace:
base:debug:StackTrace:StackTrace [0x0000....] (e:\projects\clones\chromium\src\base\debug\stack_trace.cc) ...
Since I couldn't copy paste the whole stack, I will join a screenshot of what it all feels like:
I am successful in building the last revision, or at least, it appears to be successful since no errors are showing up when compiling with the toolchain recommended in Building instructions.
Luckily, the first errors aren't modal and it is possible to browse a little bit afterwards. Then, if I put the application into heavy loading (such as Facebook newsfeed), it will suddently stop responding in a silent way. Mouse hovering effects will not show anymore and reloading the page will result in infinite loading. This behavior is also reproductible when right-clicking on some pages (e.g.: google's home page does it sometimes).
What could be an explanation of this not working "out of the box" with default configuration? How to fix this?
P.S.: This question is complementary to this question:
Windows chromium-browser fresh build stacktrace and anonymous fatal errors on runtime, if it can help getting the big picture of the question.
P.S.2.: I am currently trying to rebuild from start again with this slight change to see if it works out better. I will be able to see it after about 10 hours, though (yes, the build is painful on my current setup).
void CheckFreeLibrary(HMODULE module) {
BOOL result = ::FreeLibrary(module);
if (!result) {
result = ::UnmapViewOfFile(module);
}
DCHECK(result);
}
Update - 2016/07/29
Test with CheckFreeLibrary still failed in debug, but I finally found a way to resolve the issues in a build. See update 3 in superuser question. What I did was configuring the build into release mode via gn args. This is, obviously, almost impossible to debug with, so a solution / explanation is yet to be found about why it fails in debug mode. This is quite close now, though.
Update 2 - 2016/08/13
Started all over again to have a debug version again with the latest version in the repositories, and this time I was sure enough to find something. In fact, after I've run through the usual procedure to update, generate and build, I noticed that some win-core-* DLL libraries located in the Windows Kit debugger weren't copied src folder but one of those was assumed to be there during the link process. As a precaution, I've simply copied them all to be sure that any delay-load or build dependency was there. The first time chromium has launched, the errors didn't show up and thought it was resolving the issue. However, right-clicking on the Google Homepage had the same effect (no response, then browser not showing pages anymore). After closing and reopening it, errors are beginning to show up.
Is there anyone that had experienced that? I would be very happy with something like "do it on linux, it works better on this platform". I am not willing to do it without knowing it will work any better, though.
So
BOOL result = ::FreeLibrary(module);
fails in debug builds see if you have a
DWORD WINAPI GetLastError(void);
to get the real error.
I could guess
module not loaded
module is NULL
Perhaps some DEBUG statement is changing the value of module?
After setting up a unit test in VS2105 which created some COM objects using Unity I started getting the following error:
Managed Debugging Assistant 'DisconnectedContext' has detected a problem in 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 14.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\te.processhost.managed.exe'.
I had a quick look to see if anyone else had the same problems and a lot of the solutions to the problem were either to fire off the test in it's own thread or change the target architecture to x64. Neither of these solutions felt quite right to me as they are more like work-arounds to the problem.
So after little thought I realised the problem is that the COM objects are not being given enough time by the test framework to clear down. So I came up with the following solution which worked.
To fix the problem I added the following code to the tear down / test clean up method of the unit test:
_unity.Dispose();
GC.Collect();
GC.WaitForPendingFinalizers();
The first line is only need if using Unity however the main part of fix is the last two lines. They force a garbage collection and then tell the current thread to wait until it has completed. Thus allowing the COM objects to be cleared down properly.
We just "upgraded" from Visual Studio 2008 to Visual Studio 2012. We updated our unit tests and now they pass when running them individually but when I try to Run All, I got the following error:
The active Test Run was aborted because the execution process exited unexpectedly. To investigate further, enable local crash dumps either
at the machine level or for process vstest.executionengine.appcontainer.x86.exe. Go to more details: [http://go.microsoft.com/fwlink/?linkid=232477][1]
So I went to the link and followed the instructions to add the registry key to enable local crash dumps. The error message then changed to:
The active Test Run was aborted because the execution process exited unexpectedly. Check the execution process logs for more information.
If the logs are not enabled, then enable the logs and try again.
Apparently it noticed the changes that I made in the registry to enable crash. However, when I looked in %LOCALAPPDATA%\CrashDumps, no files were being created.
If I run one test at a time (or even a few tests at a time), I can get them all to pass. The problem is only with Run All.
Has anyone else encountered similar problems? If so, how did you solve them?
Essentially the same question was asked on MSDN, but the answer was something like "click the link to the crash dump". That answer doesn't help me because I don't see any link to the crash dump and I am unable to get the crash dump to be generated.
This question on StackOverflow is also similar, and ended up resulting in a bug being logged on Microsoft Connect (which looks to be deferred for some reason), but my problem might be different because my code has nothing to do with "async tasks" (I don't think).
EDIT: The problem went away, seemingly on its own, but the problem was likely an exception that wasn't being caught in the unit test code, as some of the answers below suggest. However, I'm still confused as to why the problem only appeared with Run All, and not when running smaller groups of tests or Debug All.
I had the same problem, the tests failed for apparently no reason. Later I found that a buggy method was causing a StackOverflowException. When I fixed my bug, the VS bug disappeared.
Maybe it works most of the time because you don't run the faulty code.
The best workaround I have so far is to debug all. This is done via TEST -> Debug -> All Tests. It's obviously slower but it doesn't crash.
This can happen with certain errors, such as a stackoverflow. Presumably this is crashing the test runner and so it can't continue when it hits a test that causes the problem.
The solution, therefore, is to run all tests in debug (from the Test -> Debug menu) and Visual Studio will show errors like these.
For anyone else who may need this in future: My test runner was crashing when a console specific command (Environment.Exit(-1);) was executed via the unit test. Even running in debug mode would just crash - I could not get at a useful error message.
So my scenario is different to the main question scenario in that a) debug didn't work at all b) run all vs run individually made no difference. That is because my error scenario always arose but the stack overflows of the original question did not.
The bottom line: test runner is bad and will crash if it finds something it doesn't like. You need to manually isolate and work out what the Bad Thing™ is.
For someone else looking for this: I had some code that was calling System.Environment.Exit(123), and I was unaware of this. So check for any code that terminates the process.
I've just had the same problem. It turned out that was my code - there was an infinite loop of WCF service calls. In your case this might be something else. So my proposal is to either remember (logs in version control system?) or to figure out (by excluding different tests from run, e.g. with bisection method) which place in code leads to this behavior. And wuala! It's cause of the problem and at the same time bug in code.
UPDATE
As for questions in your EDIT. It could happen that running smaller groups of tests didn't reproduce the issue. In this case, given those groups included all tests, one can make an assumption that some tests interfere. Maybe some static data or fields in a test class?
As for running tests in debug mode - I'm not surprised. Visual Studio test runner behaves different in "Run" mode vs "Debug" one.
I had a similar problem except that it wasn't a stackoverflow exception. It was caused by my project under test using Entity Framework and the NUnit project not having references included to the EntityFramework and EntityFramework.SqlServer modules. Adding the references to Entity Framework modules fixed it.
Just had the same problem. Closing and reopening visual studio fixed it for me.