Maybe it's just a stupid case of PEBKAC, but recently, when fixing C# compiler errors, I frequently run into this problem:
I press enter on the first error (to jump to the code and fix it)
The error gets removed from the list (still normal for JIT code)
Previously, I would now just shortcut to the Error list, press down once, then Enter and fix the next bug. But now the list just seems to put my selection at a random error, not at the next one in the file.
I have the list sorted by error number (2nd column) which seems to coincide with File and Line sorting. I'm using VS2013.
Maybe I changed some setting by accident? Or is that a VS2013 bug? (Haven't been using it for that long, and 2008 never had that problem AFAIK)
PS: It could be the case that that problem has always existed, but I didn't notice because it doesn't happen in C++ obviously, and I didn't have such a mass of errors at once (big refactoring atm)
Related
When I search for something in the Project navigator, some results are missing from the list. If I delete my query and write it again, it starts to work again - but only in come cases.
What is this issue and how can I get around it?
UPDATE: This issue has been fixed in Xcode 12.0.1.
Original answer:
This is a bug in Xcode 12 caused by typing too fast. (Yeah, I know...)
Essentially, what happens is that Xcode starts fetching the list, but if you type the second character before the first query finishes (or the third before the second finishes, you get the idea), you'll get a list with missing items. What likely happens is that Xcode tries to filter the previous list to save time instead of querying all files, and in this case, it filters the incomplete list instead of waiting for the query to finish.
There are 2 easy ways to get around this issue for now:
Use the Open Quickly menu instead (⌘⇧O, Cmd+Shift+O)
Type slower. (no joke, this is what I usually do)
Hopefully this will get fixed soon.
I am trying to learn fortran. I wanted to replicate a certain step in a paper but I ran into trouble.
I compiled the file AERsimulation.f95 (I turned on all debugging functions in gfortran I am aware of) I could generate an .out file without any errors (a lot of warnings, however...)
When I tried to run the .out file I got the error message
Fortran runtime error: Index '0' of dimension 1 of array 'k' below lower bound of 1
Now, it is quite difficult for me to understand why exactly this happens. I guess, my question is, whether there is a better way of debugging, so that I can see and click through the code 'live' and see why the error occurs. (I am thinking of the matlab-debugger for instance...)
Any suggestion/hint is very welcome
The files I use are
AERsimulation.f95
AERDATANB.TXT
Thank you very much
Best
Derrick
The meaning of your error message is that you try to access an array element at the position 0 of the array. Arrays in Fortran start at 1 by default.
If you are looking for a better way to debug, try gdb (command line) or if you prefer a graphical interface you can try the Netbeans IDE. It has (limited) support for Fortran an a debugging mode where you can click line by line through the code and see the values of all variables and so on.
On command line try:
gdb name_of_executable
run
the debugger will stop at the line which causes the error.
In Visual Studio, is it possible to edit assembly language code while stepping through each statement (so that statements in the program can be modified while the program is running?) It would be useful to modify statements in a program while the program is running (for debugging purposes), but I'm not sure if this is possible yet.
You can modify the source code, but it doesn't get reassembled to produce a new binary during your debugging session. The debugger will tell you the "source no longer matches the code" but you can still step. Your display may be confusing because, well, the source code no longer matches the object code :-} I often add comments to instructions or in blank lines, which gets me the complaint, but you can still single-step and see the right source lines in this special case.
I think you can manually modify the memory containing the instruction you want to patch. I've not ever bothered to do this; its easier to set a breakpoint where I'm at, re-assemble, and then run till the breakpoint.
You can modify all the registers and data memory pretty easily (actually you have to use this to modify the code memory, I think!).
A really useful thing to do is "Set Next Statement" to set the PC back to a somewhat earlier place in the code; you can often then step forward to point of failure, if the registers and memory aren't changed. (put cursor in your source or disassembly window, click on a line, then right-click "Set Next Statement")
I have a project in C#/.NET4 in which there are several nested loops within a method. Recently, I have noticed that I can't mouseover to inspect variable values within these loops. In fact, if I go to the immediate window and try to research the value manually, the compiler reports that the variable doesn't exist. When I mouseover nothing appears, but its only at certain parts of one method. If I look in other parts of the same code (I haven't been able to figure out what the difference between the parts is in terms of debugging) mouseover works fine. I have things as simple as:
for (int i = 0...)
{
XX Breakpoint is hit here XX
}
and I can't get the value of i! Is there some limitation of the VS2010 debugger that is a known issue where it would affect only certain sections of code? I deleted all my PDB files, completely rebuilt the files from scratch, and still it doesn't seem to know the variable exists. Any advice is greatly appreciated on this one.
You're stepping through C/C++ code and have just called a Win32 API that has failed (typically by returning some unhelpful generic error code, like 0). Your code doesn't make a subsequent GetLastError() call whose return value you could inspect for further error information.
How can you get the error value without recompiling and reproducing the failure? Entering "GetLastError()" in the Watch window doesn't work ("syntax error").
As mentioned a couple times, the #err pseudo-register will show the last error value, and #err,hr will show the error as a string (if it can).
According to Andy Pennell, a member of the Visual Studio team, starting with VS 7 (Visual Studio .NET 2002), using the '#' character to indicate pseudo-registers is deprecated - they prefer to use '$' (as in $err,hr). Both $ and # are supported for the time being.
You can also use the $err pseudo-register in a conditional breakpoint; so you can break on a line of code only if the last error is non-zero. This can be a very handy trick.
Some other pseudo registers that you may find handy (from John Robbins' outstanding book, "Debugging Applications for Microsoft .NET and Microsoft Windows"):
$tib - shows the thread information block
$clk - shows a clock count (useful for timing functions). To more easily use this, place a $clk watch then an additional $clk=0 watch. The second watch will clear the pseudo register after the display of the current value, so the next step or step over you do gives you the time for that action only. Note that this is a rough timing that includes a fair bit of debugger overhead, but it can still be very useful.
ERR,hr in a watch window usually does the trick
"edit and continue" add the code so you can see the error (just don't create a new global variable to store it). It works really well if you can quickly put a call to a pre-existing function that executes this kind of error handling code.
As a bonus, you can leave the new code there for the future too.
If you can't do this, then QBziZ is right "ERR,hr" does it.