I'm completely new to this but I'm taking a course in Audio Plugin Development as a way to try and improve my understanding of C++. I've hit a wall quite early where the plugin caused Logic to crash. I'm using Xcode and Juce and when I got to this point in Xcode and built the plugin, it said 'build succeeded' and opened Logic, which then crashed, directing me back to this line of code
thread 1: breakpoint1.1
If I open Logic independently without Xcode, it's not crashing, but when I reset and rescan plugins, I get a crashed validation for that plugin
Logic: crashed validation
I don't fully understand where it's directing me to or where the problem is, I retraced my steps in following the directions in the course and I think I've done everything correctly. In the previous step I did the initial build of the plugin and that worked fine, without any crashes.
I've tried deleting breakpoints and running again but it's still the same problem. As I say, I'm very new to this so could be something very simple but any help would be great. Thanks a lot
Related
I've just updated a major C++ project from VS2010 to VS2019, and I'm having problems getting Edit and Continue to work like it used to, specifically in relation to the 'Require source files to exactly match the original version' setting (which I will refer to as the 'require match' setting, because it's shorter).
I'm used to running my program, making changes to the source code while it's running, then setting a breakpoint to catch the running application just before the changed code. When the breakpoint is hit, I could hit F5 to rebuild and continue.
In VS2019, it seems that Edit and Continue will not work without the 'require match' setting, but setting breakpoints in existing code cannot be done with 'require match' once any changes are made.
There's a couple of workarounds, but none are ideal. It's possible to turn on "require match" to build and run the program, then after some code changes are made, turn it off to set the breakpoint, then turn it back on again for the rebuild and continue. That's a huge pain. It's possible to use pause and continue to force a rebuild of any edits, but this only works if the code change is complete enough to build. If I want to break to inspect a variable, this doesn't work. Once or twice I did manage to set a breakpoint on changed code, and it automatically went to the stale code, which is acceptable, but I can't get this to happen now. Also, now I have breakpoints that are showing as valid on edited code that has been rebuilt and I know is running, but the breakpoints are not being hit.
Any solutions here, or does Edit and Continue simply not work as well as it used to?
Here's some pictures...
Firstly, while my program is running, I made some change to surfdraw_panels.cpp, then went to add a breakpoint. It shows the following message...
Then loads up a [stale] version of the code, with the breakpoint set in the stale code...
Other times, when I make a change, I get a different result, and it won't allow me to set a breakpoint at all... In VS2010, it was possible to turn off the 'require match' setting and still use 'Edit and continue', but VS2019 will not allow this, even though it is still the recommended 'solution' in the message!
Github project that shows the issue is below. It's a simple MFC app, dialog based, created by the new project wizard in VS2019. There is a single button on the dialog, and some simple code to do something in the button. To recreate the problem, start the app in the debugger, then make a change to OnBnClickedButton1(), and then try to set a breakpoint.
https://github.com/surfdabbler/MFCApplication1
Not quite understand your specific situation and operation, because there are not some pictures and code to explain the issue in detail.
But this function which I used could break into the changed code during debugging with require match option. You should move your cursor back to the changed code and then Debug the below code step by step. And when you move the cursor back to the changed code, vc++ project will rebuild the changed code automatically and you do not have to stop debugging and restart build.
Update 1
I also faced the same behavior in my side. And since we could not handle the issue here any more, I reported the issue on our DC Forum.
You can vote it and add any comments if I did not describe the issue in detail so that it will get more Microsoft's attention. And I hope the Team will give you a satisfactory reply.
I receive this error whenever I try to preview a freshly created swiftui view.
messageRepliedWithError("Connecting to launched interactive agent 9297", Optional(Error Domain=com.apple.dt.ultraviolet.service Code=17 "connectToPreviewHost: Failed to connect to 9297: Error Domain=com.apple.dt.ProcessAttachUtilities Code=3 "Target process 9297 exited prematurely, likely crashed" UserInfo={NSLocalizedDescription=Target process 9297 exited prematurely, likely crashed}" UserInfo={NSLocalizedDescription=connectToPreviewHost: Failed to connect to 9297: Error Domain=com.apple.dt.ProcessAttachUtilities Code=3 "Target process 9297 exited prematurely, likely crashed" UserInfo={NSLocalizedDescription=Target process 9297 exited prematurely, likely crashed}}))
I have no idea how to fix this so I can see previews again. I am on the latest Catalina 10.15.1
I found the Preview Canvas to be extremely buggy as well. Or maybe swiftUI code has a lot of undesired side effects.
In many occasions I found that Clean Build Folder, then kill Xcode, start Xcode, do a full Build may (sometimes) fix the problems. Until I make a tiny change somewhere... Then the whole circus starst again.
In practice this is very time consuming and basically unworkable. I found it more efficient to not use the preview canvas at all and just run the code. It is quicker, more reliable and in the end saves lots of time and frustration.
At the same time I think it is a bit of a shame on Apple. Most frustrating of all (for me at least) is that documentation is virtually non existing. It is all trial and error. Mostly error.
In short: my experience is that it is better not to use swiftUI Previews for anything beyond the very basic (yet).
I had the same problem with mine, I went through a couple of steps, so I will mention everything I did hopefully it helps someone.
But it's worth mentioning that I think the error was caused by Xcode trying to connect to the preview which failed all the time, because I was using an iPhone 8 preview.
Also I was able to use iPhone 8 preview after a while again. This looks like a buggy Xcode.
Steps.
1. Clean build folder and your derived data.
2. Close XCode Completely.
**Key Step. Open Xcode again and change your preview to iPhone XS or iPhone 11.
See the image below.
I had same issue. It was very confusing. I am using FirebaseFirestore pod in my podfile and when I remove FirebaseApp.configure() from AppDelegate didFinishLaunchingWithOptions function preview works.
I have done this 10 times just to make sure that this is an issue, and it was issue for me. So probably any code from Firbase added in that function was problem for me.
So, by checking logs I came across this error:
Crashed Thread: 3 Dispatch queue: com.google.GDTCORFlatFileStorage
Also googling I came across those bugs:
https://github.com/firebase/firebase-ios-sdk/issues/5707
https://github.com/firebase/firebase-ios-sdk/issues/5708
Turning off the thread sanitizer worked for me (I was just playing around with settings against another project that worked), so there's one more thing to try...
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?
basically, I have a native C++ application which obviously crashed from time to time during code development. After fixing some bugs it runs rather smoothly. However, I noticed a rather weird behaviour which is very confusing to me.
It is a CMake-based project and I have an option of packaging the application into a zip file. When I run the executable from a freshly extracted zip - the application runs normally (and performance is high). However, say, if it crashes couple of times - the next start the behaviour is the same, but everything runs terribly slow. The test case I have (albeit manual) is very straightforward and I can repeat it easily.
Once the application is slowed down all I have to do is to rename the folder the application is located in and the performance rises again. Until it has crashed couple of times.
Obviously, this is not a problem once I get rid of the crashes. However, it seems to me that once the system (Win8.1 x64) detects persistent crashes it runs it in some different mode(?). And it looks like the app that I run from the IDE (MSVS2013) has received this "penalty". So it runs terribly slow even in release mode, let alone debug.
So I have a couple of questions to the community. First, have you ever observed such behaviour? Second, is the reason for slowdown indeed some system-wide information stored upon application crash? And finally, do you have an idea how to fix it?
Note: I could probably move the source folder to a different location, but it would require quite a lengthy rebuild step. Moreover, I'm just curious about what is going on. Also, system restart and full rebuild in the same folder didn't help.
Some context: the application uses Qt4 (also, Qt plugin system), MITK, ITK, VTK, CTK, OpenCASCADE, glew and related libraries all build from source on this machine.
Cheers,
Rostislav.
Pretty much a year after asking this question, and having the problem "self-resolve", I think I found the answer and decided to post it here in case someone would run into similar problem.
It seems to me that my application was put by the system into the fault-tolerant heap (FTH) after several crashes. Some more information on FTH can be found on MSDN. It might make sense to disable the FTH on the developer machine (at least temporarily) when debugging a particularly nasty crash.
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.