FYI, I am using a MCVS 2013 to build and run my program. However, I kept getting the error as shown in the picture, I have try to google the solution out, but there are no much information available. Besides that, I also getting 127 warnings. Some one from here please tell me how to prevent this error happen. Thanks!
In the properties page for your project, under the Linker -> Debugging tab, you need to use true or false instead of Debug as shown in the figure I attached.
Related
I'm currently (trying) to develop an app with Worklight Studio 5.0.6 and Dojo (Mobile) 1.8.3. I have a really hard time to to find a proper method for debugging. After waiting 5-10 minutes for the build an deploy-process on the server, an error usually looks like this in the Chrome debugger:
How am I supposed to track down this error in MY source? The whole stack trace consists entirely of Dojo code which generates an absolutely useless error message after 20 abstraction layers.
Seriously, how do you guys handle this in real life? What methods do you use for debugging Dojo-driven apps in the browser?
spyro
For dojo.parse errors, I find it useful to pause the Chrome debugger on all exceptions (the purple icon on your screenshot, should be blue). You usally get more details about the cause of the error, the name of the DOM node being parsed, etc. in the first exception being raised.
Rémi.
Debugging dojo based application should be the same as debugging any javascript application.
Usually I will follow these steps:
add console.log() somewhere in code: this is fast and most of time this is enough.
set breakpoint in debugger: if step 1 is not enough, you can base on error information to set breakpoint before error line, then step in or step out.
comment out recently changes: for some error which is hard to find the error line, for example, parse error in your case, the good way is comment out your recently changes one by one till back to your last working version. Or, return to your last working version, then add code back one by one.
Create a simple application to reproduce the error : if your application is very complicate and it is hard for you to follow above methods, you can try to create a new application which mimics your current application but with simple logics and try to reproduce the error.
Based on experience : Some errors, for example, extra ',' in the end of array which works at chrome and firefox, will report a nonsense error information at IE. Debug these kinds of errors is very difficult, you can base on your experience or do a google search.
Did you provide isDebug: true in your dojoConfig? Also, try to see if the same occurs in other browsers.
Update: I recently discovered that there are issues with Google Chrome and Dojo debugging and I think it has to do with the asynchronous loading of files. As you can see in the provided screenshot of #spyro, the ReferenceError object is blank (which you can notice because of the empty brackets {}). If you want to solve that, reopen the console of Google Chrome, (for example by tapping F12 twice). After reopening the ReferenceError should not be empty anymore and now you can expand that object by using the arrow next to it and get a more detailed message about what failed.
Usually what I do in situations like that is to place a breakpoint inside the error callback (line 3398 in your case) and then look into the error variable ("e").
I am not sure how familiar you are with the Web Inspector, but once you hit the breakpoint open the Web Inspector 'console' and check for the error properties "e.message" and "e.stack" (just type in "e.message " in the console).
Also, during development it is better to avoid Dojo optimization / minification, which greatly improve your debug-ability.
Bottom line is to try to place the breakpoint before the error is thrown.
How to avoid the window "No source available" while stepping into debug mode on VS2010 SL5
In Tools, Options, Debug, General Page. Check if you have 'Enable .NET Framework source stepping' enabled, if it is enabled, disable.
I tried all the suggested fixes; Nothing worked for me.
I finally figured out the solution after several hours of trial & error iterations.
It turns out that the 'No Source Available' error is due to a stack-overflow within the VS debugger env.
The C/C++ code function that was supposed to be stepped-into (by VS debugger), was using a variable that was initialized to a stack array of a few MB in size. When I replaced this with a heap allocation, VS was successfully able to step into the code.
This worked for me.
Please note that in my case, the actual code (with the stack allocation) ran without a stack-overflow error within the debugger (if I skip the No source available error). It was just that VS's debugger's was not able to step-into a particular function sitting inside another C/CPP file, because of the internal stack overflow.
Hope this helps.
You can hit Shift+F11 to step out and it will complete whatever unavailable function it is in and stop at the next line (it may be unavailable as well, but continue to use Step Out until you get to code you want to examine.)
Regarding VS2019, a description for the issue is provided at MSDocs.
For the requisite vcruntime and ucrt source files, the problem can occur after importing from a previous VS version which has since been uninstalled.
To prevent VS from using the old directories, find the solution property pages and navigate to the Debug Source Files Dialog Box.
Click the tick button to check the entries where any invalid ones can be removed.
The vcruntime and ucrt source should always exist in the directories, and the path at the top of the Browse to find source code dialog should always show the correct path.
In my case, because of a venerable drive bug, it is given to prompt for the "D" drive instead of the "C" drive. Further, the provided path cannot be pasted over to refresh the view, so, if none the wiser, one has to use the dialog to navigate all the way up to the required location from the desktop or equivalent.
Here there is an extension for this issue:
http://erwinmayer.com/labs/visual-studio-2010-extension-disable-no-source-available-tab/
But in my own experience before finding this article (I was in page but I was trying to fix it myself without reading article) I have fixed this problem just by accepting a confirmation message saying something like "Selected source file is different from compiled assembly. Are you sure you want to use this file for debug?". But I can't remember exactly what I did to get this message. I think there was a linklabel which I clicked on "No source available" window and then confirmation message appeared and after confirm the problem ran away.
The only error I ever get is SIGABRT in main. This is getting incredibly frustrating as I have to guess what line caused the error and why.
This is a far cry from visual studio's informative error messages. It's basically like sending off an entire novel to an editor and the only notes you get back are: "There is a problem somewhere in your book. There may be many or just one and they are either gramatical or to do with spelling."
I just don't know how anyone can work like this. What am I doing wrong? Surely I'm missing something essential.
Write some NSLog() into your code and you'll see it in the console. It's a great help to narrow down a crash.
if you have encountered memory problems (aka – your app crashes for no apparent reason because you attempted to use an object that you deallocated to soon) setting NSZombieEnabled = YES can help you diagnose the problem.
Normally, when your app crashes in this way and you look at the log it tells you nothing (thanks Apple!). However, if you select your executable (under Executables in Xcode), hit the info button (round blue thing at the top), select arguments and put this in the bottom screen NSZombieEnabled = YES the log will give you more information.
Now, if your app crashes the log will have an indication of the object you attempted to access that has already been deallocated. Not forget to turn it off before you deploy it – you don’t want a bunch of nszombies running around your clients phones…
http://howtomakeiphoneapps.com/nszombie-and-xcode-oh-my/27/
I've got a solution in VS2010 where I can't get the code coverage working, I always end up with the error
"Cannot find any coverage data (.coverage or .coveragexml) files. Check test run details for possible errors.
I did set up everything as usual, so in the test settings I enabled the "Code Coverage" checkbox on the "Data and Diagnostics" page and chose the dll to be tested. I also added the "Re-signing key file" as we sign our assemblies. I don't know any other thing that prevents me from getting the coverage info, manually comparing the "Local.testsettings" for this solution with files from other working solutions didn't show any problems.
Any ideas what the reason might be and how to get it working?
Thanks in advance
G.
Alright,
For some reason the Test Settings were changed from "Local (local.testsettings)" to "Trace and Test Impact (traceandtestimpact.testsettings)". Don't know why that happened, now it works again...
I'm using Visual Studio 2008. The Trace output is no longer being shown in the Immediate Window any of my forms except the primary form. When it executes code from within another form (called from that primary form) the Trace output doesn't show up. It used to be fine, and one day it just stopped working. I think this is a setting in VS2008. Anyone have any idea what setting this would be under?
It's got a TraceListener in the code, and that hasn't been touched.
Can you do a quick check and see if the second project is compiling in Release or Debug? If it's Release there's a chance Trace won't be defined and Trace output hence won't show up.
Check that you're referencing System.Diagnostics.Trace, and not the Page.Trace TraceContext object. If you're just doing Trace.Write it might be resolving to the wrong place, depending on your using directives.
There's an item under Options - Debugging - General: "Redirect all Output Window text to the Immediate Window". That should do the trick.
Patrick