Hi, Dev-C 5.11 crash when I run a debug. See the pictures attached. Regards, Andrea. 2 Attachments. Jasmine Lin - 2015-05-14 Can confirm. I'm unable to reproduce this bug, but this does happen from time to time. My OS is Win7 Pro 64bit. Jul 08, 2017 dev c debug, dev c debug not working, dev c debug watch variable, dev c debugger, dev c debugger not working.
-->In this section, you'll find solutions to common issues with Visual Studio Tools for Unity, descriptions of known issues, and learn how you can help improve Visual Studio Tools for Unity by reporting errors.
Troubleshooting the connection between Unity and Visual Studio
Confirm Editor Attaching is enabled
In the Unity Menu, select Edit > Preferences and then select the External Tools tab. Confirm that the Editor Attaching checkbox is enabled. For more information, see the Unity Preferences documentation.
Unable to attach
- Try to temporarily disable your antivirus or create exclusion rules for both VS and Unity.
- Try to temporarily disable your firewall or create rules for allowing TCP/UDP networking between VS and Unity.
- Some programs, like Team Viewer, can interfere with process detection. You can try to temporarily stop any extra software to see if it changes something.
- Do not rename the main Unity executable, as VSTU is only monitoring 'Unity.exe' processes.
Visual Studio crashes
This issue can be due to the Visual Studio MEF cache being corrupted.
Try removing the following folder to reset the MEF cache (close Visual Studio before doing this):
This should fix your issue. In case you are still experiencing the problem, run a Developer Command Prompt for Visual Studio as Administrator and use the following command:
Visual Studio hangs
Several Unity plugins like Parse, FMOD, UMP (Universal Media Player), ZFBrowser, or Embedded Browser are using native threads. It’s an issue when a plugin ends up attaching a native thread to the runtime, which then does blocking calls to the OS. This means Unity can't interrupt that thread for the debugger (or domain reload) and hang.
For FMOD, there is a workaround, you can pass FMOD_STUDIO_INIT_SYNCHRONOUS_UPDATE initialization flag to disable asynchronous processing and perform all processing on the main thread.
Incompatible project in Visual Studio
First, check that Visual Studio is set as your external script editor in Unity (Edit/Preferences/External Tools). Then check that the Visual Studio plugin is installed in Unity (Help/About must display a message like Microsoft Visual Studio Tools for Unity is enabled at the bottom). Then check that the extension is properly installed in Visual Studio (Help/About).
Extra reloads, or Visual Studio losing all open windows
Be sure to never touch project files directly from an asset processor or any other tool. If you really need to manipulate the project file, we expose an API for that. Please check the Assembly references issues section.
If you experience extra reloads or if Visual Studio is losing all open Windows on reload, make sure that you have proper .NET targeting packs installed. Check the following section about frameworks for more information.
The debugger does not break on exceptions
When using the legacy Unity runtime (.NET 3.5 equivalent), the debugger will always break when an exception is unhandled (=outside a try/catch block). If the exception is handled, the debugger will use the Exception Settings Window to determine if a break is required or not.
With the new runtime (.NET 4.6 equivalent), Unity introduced a new way for managing user exceptions and as a result, all exceptions are seen as 'user-handled' even if they are outside a try/catch block. That's why you now need to explicitly check them in the Exception Settings Window if you want the debugger to break.
In the Exception Settings window (Debug > Windows > Exception Settings), expand the node for a category of exceptions (for example, Common Language Runtime Exceptions, meaning .NET exceptions), and select the check box for the specific exception you want to catch within that category (for example System.NullReferenceException). You can also select an entire category of exceptions.
On Windows, Visual Studio asks to download the Unity target framework
Visual Studio Tools for Unity requires the .NET framework 3.5, which isn't installed by default on Windows 8 or 10. To fix this issue, follow the instructions to download and install the .NET framework 3.5.
When using the new Unity runtime, .NET targeting packs version 4.6 and 4.7.1 are also required. It is possible to use the VS2017 installer to quickly install them (modify your VS2017 installation, individual components, .NET category, select all 4.x targeting packs).
Assembly reference issues
If your project is complex reference-wise or if you want to better control this generation step, you can use our API for manipulating the generated project or solution content. You can also use response files in your Unity project and we'll process them.
Breakpoints with a warning
If Visual Studio is unable to find a source location for a specific breakpoint you will see a warning around your breakpoint. Check that the script you are using is properly loaded/used in the current Unity scene.
Breakpoints not hit
Check that the script you are using is properly loaded/used in the current Unity scene. Quit both Visual Studio and Unity then delete all generated files (*.csproj, *.sln) and the whole Library folder.
Unable to debug Android players
We use multicast for player detection (which is the default mechanism used by Unity), but after that we use a regular TCP connection to attach the debugger. The detection phase is the main issue for Android devices.
Wifi is versatile but super slow compared to USB because of latency. We saw a lack of proper multicast support for some routers or devices (Nexus series are well known for this).
USB is super-fast for debugging, and Visual Studio Tools for Unity is now able to detect USB devices, and talk to the adb server to properly forward ports for debugging.
Issues with Visual Studio 2015 and IntelliSense or code coloration
Try upgrading your Visual Studio 2015 to update 3.
Known issues
There are known issues in Visual Studio Tools for Unity that result from how the debugger interacts with Unity's older version of the C# compiler. We're working to help fix these problems, but you might experience the following issues in the meantime:
When debugging, Unity sometimes crashes.
When debugging, Unity sometimes freezes.
Stepping into and out of methods sometimes behaves incorrectly, especially in iterators or within switch statements.
Dev C++ Crashes When Compiling
Report errors
Please help us improve the quality of Visual Studio Tools for Unity by sending error reports when you experience crashing, freezes, or other errors. This helps us investigate and fix problems in Visual Studio Tools for Unity. Thank you!
How to report an error when Visual Studio freezes
There are reports that Visual Studio sometimes freezes when debugging with Visual Studio Tools for Unity, but we need more data to understand this problem. You can help us investigate by following the steps below.
To report that Visual Studio freezes while debugging with Visual Studio Tools for Unity
On Windows:
Open a new instance of Visual Studio.
Open the Attach to Process dialog. In the new instance of Visual Studio, on the main menu, choose Debug, Attach to Process.
Attach the debugger to the frozen instance of Visual Studio. In the Attach to Process dialog, select the frozen instance of Visual Studio from the Available Processes table, then choose the Attach button.
Pause the Debugger. In the new instance of Visual Studio, on the main menu, choose Debug, Break All, or just press Ctrl+Alt+Break.
Create a thread-dump. In the Command window, enter the following command and press Enter:
You might need to make the Command window visible first. In Visual Studio, on the main menu, choose View, Other Windows, Command Window.
On Mac:
Open a terminal and get the PID of Visual Studio for Mac:
Launch the lldb debugger:
Attach to the Visual Studio for Mac instance using the PID:
Retrieve the stacktrace for all the threads:
Finally, send the thread-dump to vstusp@microsoft.com, along with a description of what you were doing when Visual Studio became frozen.
This article continues our discussion on debugging software crashes. Here we focus on memory corruption crash symptoms. We will also look at the special considerations in debugging C++ code crashes. Finally we will look at techniques to simplify crash debugging.
Debugging Memory Corruption
Programs store data in any of the following ways:
| Global | All variables of objects declared as global in a C/C++ program fall into this category. This also includes static variable declarations. |
| Heap | Memory allocated using new or malloc is allocated on the heap. In many systems, stack and heap are allocated from opposite sides of a memory block. (See the figure below) |
| Stack | All local variables and function parameters are passed on the stack. Stack is also used for storing the return address of the calling functions. Stack also keeps the register contents and return address when an interrupt service routine is called. |
Memory corruption in the global area, stack or the heap can have confusing symptoms. These symptoms are explored here.
Dev C Crashes When Debugging Iphone
Global Memory Corruption
If a global data location is found to be corrupted, there is good chance that this is caused by array index overflow from the previous global data declarations. Also the corruption might have been caused by an array index underflow (array accessed with a negative index) from the next variable declarations. The following rules should be helpful in debugging this condition:
- If you have a debugging system which allows you to put breakpoints on data write to a certain location, use that feature to find the offending program corrupting the memory. If you don't have the luxury of such a tool, the following steps might help.
- If the variable is a part of structure, check if overflow/underflow of previous or next variables in the structure could have caused this corruption.
- If other structure member access seems harmless, use the linker generated symbol map to locate other global variables declared in the vicinity of the corrupted structure. Examine the data structures to determine if they could have caused the corruption.
- Sometimes looking at the corrupted memory locations can also give a good idea of the cause of corruption. You might be able to recognize a string or data pattern identifying the culprit. This might be your only hope if the corruption is caused by an un-initialized pointer.
- Extent of corruption might also give a clue of the cause of corruption. Try to determine the starting and ending points of a corruption (only possible if the corrupting program is writing in an identifiable pattern).
Heap Memory Corruption
Corruption on the heap can be very hard to detect. A heap corruption could lead to a crash in heap management primitives that are invoked by memory management functions like malloc and free. It might be very hard to detect the original source of corruption as the buffer that lead to corruption of adjacent buffers might have long been freed. Guidelines for debugging crashes in heap area are:
- If a crash is observed in memory management primitives of the operating system, heap corruption is a possibility. It has been observed that memory buffer corruption sometimes leads to corruption of OS buffer linked list, causing crashes on OS code.
- If a memory corruption is observed in an allocated buffer, check the buffers in the vicinity of this buffer to look for source of corruption.
- Corruption of buffers close to heap boundary might be due to stack overflow or stack overwrite leading to heap corruption (see the above figure)
- Conversely, stack corruption might take place if a write into the heap overflows and corrupts the stack area.
Stack Memory Corruption
Stack corruption by far produces the most varied symptoms. Modern programming languages use the stack for a large number of operations like maintaining local variables, function parameter passing, function return address management. See the article on c to assembly translation for details.
Here are the rules for debugging stack corruption:
- If a crash is observed when a function returns, this might be due to stack corruption. The return address on the stack might have been corrupted by stack operations of called functions.
- Crash after an interrupt service routine returns might also be caused by stack corruption.
- Stack corruption can also be suspected when a passed parameter seems to have a value different from the one passed by the calling function.
- When a stack corruption is detected, one should look at the local variables in the called and calling functions to look for possible sources of memory corruption. Check array and pointer declarations for sources of errors.
- Sometimes stray corruption of a processors registers might also be due to a stack corruption. If a register gets corrupted due to no reason, one possibility is that an offending thread or program corrupted the register context on the stack. When the register is restored as a part of a context switch, the task crashes.
- Corruption in heap can trickle down to the stack.
- Stack overflow takes place when a programs function nesting exceeds the stack allocated to the program. This can cause a stack area or heap area corruption. (Depends upon who attempts to access the corrupted memory first, a heap operation or stack operation).
Crash Debugging in C++
We have been discussing crash debugging techniques that apply equally well to C as well as C++. This section covers crash debugging techniques that are specific to C++.
Invalid Object Pointer
Many C++ developers get confused by crashes that involve method invocation on a corrupted pointer. Developers need to realize that invoking a method for an illegal object pointer is equivalent to passing an illegal pointer to a function. A crash would result when any member variable is accessed in the called method.
In the example given below, when HandleMsg() is invoked for a NULL pX, the crash will result only when an access is attempted to member variables of X. There will be no problem in calling PrepareForMessage() or HandleYMsg() for Y pointer. (For more details on this refer to C and C++ article.
Corrupted Object Pointer Access
V-Table Pointer Corruption
Dev C Crashes When Debugging Mode
Inheriting Classes
All classes with virtual functions have a pointer to the V-table corresponding to overrides for that class. The V-table pointer is generally stored just after the elements of the base class. Corruption of the v-table pointer can baffle developers as the real problem often gets hidden by the symptoms of the crash.
The figure above shows the declaration of class A and B. The figure below shows the memory layout for an object of class B. If m_array array is indexed with an index exceeding its size, the first variable to be corrupted will be the v-table pointer. This problem will manifest as a crash on invoking method SendCommand. The reason this happens is that SendCommand is a virtual function, so the real access will be using a virtual table. If the virtual table pointer is corrupted, calling this function will take you to never-never land.
For more details on v-table organization refer to C and C++ Comparison II article.
Dynamic Memory Allocation
Many C++ programs involve a lot of dynamic memory allocation by new. Many C++ crashes can be attributed to not checking for memory allocation failure. In C++ this can be achieved in two ways:
- Handle out of memory exception
- Check for new returning a NULL pointer.
Simplifying Crash Debugging
Here are a few simple techniques for simplifying crash debugging:
Obtaining Stack Dump
Make sure that every embedded processor in the system supports dumping of the stack at the time of crash. The crash dump should be saved in non volatile memory so that it can be retrieved by tools on processor reboot. In fact attempt should be made to save as much as possible of processor state and key data structures at the time of crash.
Using assert
An ounce of prevention is better than a pound of cure. Detecting crash causing conditions by using assert macro can be a very useful tool in detecting problems much before they lead to a crash. Basically assert macros check for a condition which the function assumes to be true. For example, the code below shows an assertion which checks that the message to be processed is non NULL. During initial debugging of the system this assert condition might help you detect the condition, before it leads to a crash.
Note that asserts do not have any overhead in the shipped system as in the release builds asserts are defined to a NULL macro, effectively removing all the assert conditions.
assert usage
Defensive Checks and Tracing
Similar to asserts, use of defensive checks can many times save the system from a crash even when an invalid condition is detected. The main difference here is that unlike asserts, defensive checks remain in the shipped system.
Tracing and maintaining event history can also be very useful in debugging crashes in the early phase of development. However tracing of limited use in debugging systems when the system has been shipped