Edit : If you're seeing this same problem (and you're accustomed to NOT seeing this under VS2010) please comment below so I know it's not just me - but be sure to check Han's answer to make sure none of those scenarios appear...
I've been updating my app to run with .NET 4.5 in VS2012 RTM and noticing something that I don't quite understand and that is unexpectedly green highlighted statements (instead of yellow).
Now I'm well aware of what this is supposed to mean, and the IDE is even showing me a little explanation tooltip.
This is the next statement to execute when this thread returns from
the current function
However there's absolutely nothing asynchronous or thread based about this code. In this simple example I'm sure you'll agree that string.ToUpper() won't be off in another thread. I can step through the code no issue.
There's nothing else going on and I am on the main thread as you can see here.
I am using async and await and MVVM-Light (the above method is the result of a RelayCommand) but I still get this behavior even when the code path is directly off an event handler such as PreviewKeyDown.
If I create a new app I cannot duplicate this - the coloring is yellow as expected - even when using await.
Anybody got any idea? It's starting to drive me crazy!!
It is green when the current instruction pointer is not exactly at the start of the statement. Some common causes:
Common in threaded code, setting a breakpoint in one thread and switching context to another. The other thread will have been interrupted by the debugger at an entirely random location. Often in code that you don't have source code or debugging info for, like String.ToUpper(), the debugger can only show the "closest" source code
Using Debugger + Break All to break into the debugger. Same idea as above, the instruction pointer will be at a random address
Getting an exception in code you don't have debugging info for. The editor shows the last entry in the Call Stack that it does have source code for. You need the call stack window to see where the actual exception was raised. Or the Exception Assistant, its reason for being
Debugging optimized code. The jitter optimizer scrambles the code pretty heavily, making it likely that the debugger can't show the current location accurately
Having out-dated debugging info or editing the code while debugging
Debugging code generated by the x64 jitter, happens when the project's Target Platform setting is AnyCPU. The x64 jitter has a number of chronic bugs that are not getting fixed, generating incorrect debugging info is one of them. Problems that were not addressed until it was completely rewritten, done by the RyuJIT project and first available in .NET version 4.6. Targeting x86 in your EXE project is the workaround.
I understand that this is old post yet I would like to answer the question with my experience.
I have encountered same issue recently in one of my WCF application. After debugging and closely looking service logs and I find out that my code was giving this error because service was hitting max allowed limit for code execution and once the service hit max allowed time limit it was trying to offload the current debugging session.
ERROR IN GREEN STATEMENT: this is the next statement to execute when thread return
So avoiding this issue you can try to look any potential code(Code/Service Timeout or any other code block) which is trying to offload your currently executing code context and try to fix it, furthermore original explanation given by #Hans is still very much relevant for trouble shooting this issue.
Actually, I am also facing this issue. This is because I missed some layout component in landscape mode, So check all the Id's and components and Run, you will not get this error.
Related
I have a random Runtime Error 216 that appears on application close.
I have debugged as far as I can and the error is thrown in SysUtils.FinalizeUnits.
I have gone over the code and ensure all created objects are freed.
The number on the runtime error, 0040054A, is not present in the mapfile. Do you know what this means?
Can anyone tell me how to find out what is throwing the error?
This is VERY OLD Delphi problem - wrong exception handling in unit initialization/finalization process.
The problem easy to reproduce - just make any program error/exception (division by zero for instance) in initialization block of any unit. The exception will be created correctly. But then, before the exception rise, the unit finalization process destroy the exception object. And thus, when the exception object accessed, the "runtime error 216" occured.
I'd suspect a memory leak (all Runtime Errors 216 I've encountered so far were) and use a profiler (visual inspection is never as good as a tool). Since you're using Delphi XE, you should give AQTime a try (it's included), see also
Delphi - Check if memory is being released "on time"
Kind regards, Frank
Since runtime error 216 is an access violation, this may indicate that you're attempting to use something that you've already freed.
Addresses in the map file are based at 0, but that's not where your EXE file gets loaded into memory. Your EXE gets loaded at its preferred base address, which is usually $400000. Subtract that from the address you have. The address you're looking for in the map file is $0000054a.
There was a similar question, Read:
How to debug a crash that only occurs on application shutdown? (Delphi)
Consider using Memory profiler, this may help identifying live objects after app was terminitated.
I suggest you try the FastMM Full Debug Mode, and either statically link that into your app, or use it as a package (if your app uses packages).
You can use the method I used to fix mine.
I commented out the main program, and added code back until it failed.
Turns out that it did not want me to call couninitialize at all. Did not throw an error at the time, but failed after program termination with a 216. Removing the offending statement fixed it.
Since this was maybe 6 statements before end. statement, I don't imagine it will matter.
This method is easy if you are consistent about using // for comments. I moved IO statements that needed curly brackets to a procedure.
On Microsoft's oficial web site it is mentioned that, this issue can occur if your computer is infected with a SubSeven Trojan virus.
Antivirus software and windows registry cleaner should help.
I have developed a fairly large C++ program in VS 6.0 on a Win XP platform, and have now migrated to a new machine running Win 7 (still running VS 6.0). The code includes a function to instantiate and run a CFileDialog object to find and open an ASCII file with a specific extension from a specific initial directory. But now, the program hangs on the line
if (t1.DoModal()==IDOK)
...where t1 is the CFileDialog instance.
To investigate why the standard CfileDialog class stopped working, I created a separate test project in VS 6.0 with a simple dialog with one button, containing this code:
void CFileDialogTestDlg::OnOpenFileDialogButton()
{
CFileDialog t1(true);
if(t1.DoModal()==IDOK)
{
CString s3=t1.GetPathName();
MessageBox(s3);
}
}
This test works fine and displays a useable file dialog. I can also duplicate what I want in my large project in terms of initial directory,etc by modifying the m_ofn members of t1.
But putting this code into my large project (ie modifying the relevant button in it) still hangs on the DoModal() line. It seems unproductive trying to trace into a standard MS class, the internals are impossible to understand in a reasonable timeframe.
When I increased stackspace for my test project to match my large project (400MB), I reproduced the hanging behaviour identical to the large project.
Can anyone explain why increasing stackspace should affect file dialog execution in this way, and is there a way around the problem, bearing in mind I need the large stackspace to avoid completely rewriting my project?
I'm not sure the stack is your problem. It's been a while but I seem to recall common modals hanging if you access them from the wrong thread.
Use PostMessage() API to send commands from any thread to the thread that owns the modal dialog. It needs to be the owning (and blocking) thread that ultimately receives the command to accept/cancel the dialog so that it returns from its message pump routine.
If you install the Windows debug symbols, you can see the full call stack of your blocking thread in a debugger.
I'm using Open MPI 1.8 on Gentoo 3.13 to manage the data transfer from one program to another via a server/client concept. Both the server and the clients are launched via mpiexec as separate processes. After some days (this is quite a heavy computation...), I sometimes receive the error
mpiexec noticed that process rank 0 with PID 17213 on node XXX exited on signal 26 (Virtual timer expired).
Unfortunately, the error is not reproducible in a reliable way, i.e., the error does not appear always and not always at the same point in the program flow. I also experienced this error on other machines. I already tracked the issue down to the ITIMER_VIRTUAL which, upon expiration, delivers SIGVTALRM (see, e.g., http://man7.org/linux/man-pages/man2/setitimer.2.html). In the BUGS section of the man page, it says that
Under very heavy loading, an ITIMER_REAL timer may expire before the signal from a previous expiration has been delivered. The second signal in such an event will be lost.
I wonder if something similar might also hold for ITIMER_VIRTUAL? Did anyone experience similar problems and can confirm the error?
The only workaround I can think of is to invoke setitimer(...) and try to manipulate the timer myself. However, I hope there is another way since I can't always modify the clients' source code. Any suggestions?
Since this question has not been answered officially, I will do it on behalf of Hristo (#HristoIliev: I hope this is ok for you). As was pointed out in the first comment to my question, there is not a single hint in the Open MPI source code which can have caused the virtual timer expiration. Indeed, the timer problem was related to a third-party library which made the code crash after an unpredictable time (depending on the current loading of the machine).
I have been asked to debug, and improve, a complex multithreaded app, written by someone I don't have access to, that uses concurrent queues (both GCD and NSOperationQueue). I don't have access to a plan of the multithreaded architecture, that's to say a high-level design document of what is supposed to happen when. I need to create such a plan in order to understand how the app works and what it's doing.
When running the code and debugging, I can see in Xcode's Debug Navigator the various threads that are running. Is there a way of identifying where in the source-code a particular thread was spawned? And is there a way of determining to which NSOperationQueue an NSOperation belongs?
For example, I can see in the Debug Navigator (or by using LLDB's "thread backtrace" command) a thread's stacktrace, but the 'earliest' user code I can view is the overridden (NSOperation*) start method - stepping back earlier in the stack than that just shows the assembly instructions for the framework that invokes that method (e.g. __block_global_6, _dispatch_call_block_and_release and so on).
I've investigated and sought various debugging methods but without success. The nearest I got was the idea of method swizzling, but I don't think that's going to work for, say, queued NSOperation threads. Forgive my vagueness please: I'm aware that having looked as hard as I have, I'm probably asking the wrong question, and probably therefore haven't formed the question quite clearly in my own mind, but I'm asking the community for help!
Thanks
The best I can think of is to put breakpoints on dispatch_async, -[NSOperation init], -[NSOperationQueue addOperation:] and so on. You could configure those breakpoints to log their stacktrace, possibly some other info (like the block's address for dispatch_async, or the address of the queue and operation for addOperation:), and then continue running. You could then look though the logs when you're curious where a particular block came from and see what was invoked and from where. (It would still take some detective work.)
You could also accomplish something similar with dtrace if the breakpoints method is too slow.
I have a multi-threaded application that I'm debugging inside the IDE (Visual Studio 2008, Win7-64, C++).
For "debugging" purposes, I "pretend" that I always have a single processor (the program detects the number of local processors), but the program design establishes a minimum of two threads (e.g., the "main thread" which handles GUI and event traffic, and a second "processing" thread where work is moved off of the "main thread"). (In a "production" build there would be a single main thread, and one-or-more "processing" threads depending on the number of detected processors.)
ISSUE: Breakpoints in the code (within the IDE) sometimes are triggered, and sometimes not. Re-running the program may "catch" on a break point where the previous run it did not "catch" (no source code changes or rebuild is performed to see this change-in-breakpoint-catch-behavior, the program execution path is identical).
(I mostly only care about triggering breakpoints in the non-GUI/non-main-thread, but I assume that should not matter.)
QUESTION: Is there a way to make these break points catch more "reliably"? (What influences whether a break point "catches" or not?)
I'm aware of, and NOT concerned with the following:
Source is out-of-sync with latest linked executable
Build is not "debug" (no debug symbols available)
"Clean build" is needed (debug artifacts out-of-date)
"Step Over/Into" may not work properly when another thread "breaks"
during that first thread's stepping operation
On web searches, there was a mention of possibly setting the compiler setting to "x86" and not "Any Processor" to catch breakpoints, not sure why that might matter ... ?
Finally, yes, of course, all logic "should" be tested in a single-threaded application (e.g., re-factor to ensure deterministic single-threaded execution for unit and regression tests). However, for the current testing, I need to be in the "real" application (think "integration testing" or "systems integration").
Normally breaking is extremely reliable. Here are some things to try:
Hard code a breakpoint with DebugBreak(). This should always be caught, but if this exhibits the same broken behavior, you have narrowed down the problem.
Where you currently have the bp set, add a line to print to screen/file, and set the breakpoint on that line. This is to be certain this line is really even being hit. You may have a strange, unexpected bug that is actually skipping the entire section unexpectedly and this is necessary to be sure.
Try with and without any optimizations. Debugging works best with all optimizations off, but even with deadstripping and inlining features at work, breakpoints are expected to still work. Does this issue occur even with optimizations off?
You say ISO C++, does this mean you've actually switched off all microsoft extensions? I've never compiled this way in visual studio, but if you have, try switching extensions back on and see if that has any effect.
I'm going to agree with VoidStar and other comments. I have worked with VC6, VS2005, VS2008 and VS2010 and I have debugged pretty complex multi-threaded apps with them and breakpoints have always been reliable for me.
With once exception. For projects that use DLLs, sometimes breakpoints that are set in code from a DLL do not work. This is not because VS misses the breakpoint, but instead because the debugger cannot map that line of code to an actual location in the compiled code, probably because the pdb file could not be loaded for some reason. When this happens you see a hollow red circle in the left margin of the breakpoint line instead of the full red ball. Could this be your problem?
I have not figured out why this happens sometimes, but in my experience it only happens for breakpoints in modules that are not the main project being debugged. A workaround that I use is to start the debugger from the DLL, putting the exe in the startup debug configuration for the DLL project. Another trick that sometimes helps is to have all the projects in a single solution, and have them all setup with correct references, so that with one compilation you can rebuild the whole thing.
Good luck, I hope this helps.