When I write C++ with MS Visual Studio, I use the following statement to check my heap for corruptions. This has been an excellent tool in homing in on problems:
_ASSERTE( _CrtCheckMemory() );
Basically you can scatter the above statement around your code to check the consistency of the heap.
Is there something similar that can be used in Android NDK programs to identify heap corruption at runtime - before I crash with a tombstone dump?
In Linux, similar functionality can be achieved by mcheck. But, unfortunately, this can't be used on Android (however, here and here can be find mcheck.h for Android)
If your device rooted, you can try this:
Valgrind
AddressSanitizer
am dumpheap <pid> <path/where/to/save/dump> (obtain dump of process's native heap)
For dump analyzation, you can try use deprecated Android Monitor (this link should help to enable native heap dump)
Related
recently I have bougth a ESP32 devkit and a low budget FT4232H jtag adapter which I managed to setup in VSCode using the Espressif-idf plugin.
Basically it seems to work so far. I can build, flash and monitor the ESP32 from VSCode. Also also managed to setup the debug configuration, but I am still missing some features in while debugging.
I can step through the code, watch variables and see the call stack.
But I can't see periphals, registers or memory
I guess I have to set some more options in GDB, OpenOCd or even ESP32 config but I don't know which ones.
Any ideas were i have to dig?
You appear to be almost there.
I have a very similar interface with the memory loading afterwards but only after stepping into certain operations.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/jtag-debugging/debugging-examples.html
Following this document produced by espressif. Memory can be accessed and stepped into using the keyboard shortcut (x) when using openOCD.
Give that a try.
In Xcode's Instruments, there is a tool called Counters that exposes low-level counter information provided by the CPU, such as the number of instructions executed or number of cache misses:
This is similar to the Linux syscall perf_event_open introduced in Linux 2.6.32. On Linux, I can use perf_event_open then start/stop profiling around the section of my code I'm interested in. I'd like to record the same type of stats on OS X: counting the instructions (etc.) that a certain piece of code takes, and getting the result in an automated fashion. (I don't want to use the Instruments GUI to analyze the data.)
Are there any APIs that allow this (ex: using dtrace or similar)? From some searching it sounds like the private AppleProfileFamily.framework might have the necessary hooks, but it's unclear how to go about linking to or using it.
In GNU/Linux I use Intel's PCM to monitor CPU utilization. I'm not sure if this works fine on OSX, but as far as I know the source-code is including the MacMSRDriver directory. I have no any OSX device, never test it anyway.
In case this source compiled on your device, Just run:
pcm.x -r -- your_program your_program_parameter
or if you want advanced profiling, use pcm-core.x instead or you can build your own code based on pcm-core.cpp
As announced at WWDC 2015, Clang Address Sanitizer is being brought to Xcode and OS X.
Session 413: Advanced Debugging and the Address Sanitizer
How do you enable Clang Address Sanitizer for your Xcode project?
Address Sanitizer has been added as a new feature in Xcode 7.
Use the Runtime Sanitization > Enable Address Sanitizer flag in your scheme to enable the option.
git will then shown this change to your .xcscheme file:
enableAddressSanitizer = "YES"
From the New Features in Xcode 7 document:
Address Sanitizer. Xcode 7 can build your app with instrumentation designed to catch and debug memory corruption using the address sanitizer.
Objective-C and C code is susceptible to memory corruption issues such as stack and heap buffer overruns and use-after-free issues. When these memory violations occur, your app can crash unpredictably or display odd behavior. Memory corruption issues are difficult to track down because the crashes and odd behavior are often hard to reproduce and the cause can be far from the origin of the problem.
You enable the address sanitizer in the build scheme. Once enabled, added instrumentation is built into the app to catch memory violations immediately, enabling you to inspect the problem right at the place where it occurs. Other diagnostic information is provided as well, such as the relationship between the faulty address and a valid object on the heap and allocation/deallocation information, which helps you pinpoint and fix the problem quickly.
Address sanitizer is efficient—fast enough to be used regularly, as well as with interactive applications. It is supported on OS X, in the Simulator, and on iOS devices.
I'm developing a WinCE 5.0 application that uses two commercial libraries. When the application starts calling the second library it gets slowlier and then after some use, it hangs and the whole OS freezes. It has to be rebooted to work again. The thing is that I'm developing this without a physical device (a testing person installs each release and runs the tests) and without an emulator (the device provider is not facilitating an OS image).
My intuition tells me that the second library is using all the available resources (basically, handles and memory) for a WinCE 5.0 process. I have to prove this to the library vendor. So I wish to add to my logs some general process and system information. Could you recommend me which APIs to call to get this information in CE?
I would really appreciate any hint
Thanks in advance!
Windows CE provides a very robust set of APIs for a subsystem called CeLog. CeLog is what Kernel Tracker uses to collect and display it's information. You can get all the way down to scheduler calls and thread migrations if you want. The real danger with using CeLog is in collecting too much data so that making sense of it is difficult, but if you filter the collections to just your process, that should help. You could collect the data to a log file, then use Kernel Tracker to open and view that data.
Here are some good starting points for info:
Introduction to Remote Kernel Tracker
More on Remote Kernel Tracker
CeLogFlush.exe (particularly the section 'Collecting Data on a Standalone Device with CeLogFlush')
Implementing a Custom Event Tracking Library
Embedded Visual C++ 4 contained "Remote Performance Monitor" that could do just that. Microsoft retracted EVC4 as free download some time ago, but it can still be downloaded from MSDN or found on the internet.
With service pack 4 it should work for WinCE 5.0. It does not appear to work with Windows Embedded 6.0 and newer though.
When I try to debug an arbitrary CUDA application, e.g. the matrix multiplication or convolutionSeparable sample from the Nvidia GPU Computing SDK 4.0, I always get an output similar to:
Parallel Nsight Debug
CUDA grid launch failed: CUcontext: 2059192 CUmodule: 348912936 Function: _Z9matrixMulILi32EEvPfS0_S0_ii
……
……
And a file with the following content is showing up:
Parallel Nsight CUDA Debugger
The application being debugged with the Nexus CUDA debugger, was unable to
find any associated source. This could be for a number of reasons:
1) CUDA has not been initialized.
Make sure cuInit has been called, and it returned a successful result.
2) No CUDA contexts have been created.
Once a context is created, memory can be examined in the context. Each context
shows up as a single "Thread" in the Visual Studio Threads view. (Debug | Windows | Threads)
3) There are no active CUDA grids in any context.
A grid must be launched in order to hit breakpoints.
4) You have selected the "Default Context" in the Visual Studio Threads view.
This context is a placeholder shown when there are no available actual CUDA
contexts. It does not show real data.
5) No CUDA modules have been loaded.
You can see which modules are loaded in each CUDA context by showing the
Visual Studio Modules view. (Debug | Windows | Modules)
6) Symbolics were not found for the loaded .cubin.
The module needs to be built with debug information. Please specify the
-G0 switch when building.
7) A grid launch failed while running a kernel.
Each breakpoint within the corresponding “.cu” file is completely ignored during the run. When I just run the application, without Nsight Debugging, the program executes without any problems.
What can I do to tackle this problem?
My Setup:
1xIntel GPU and 1x NV 570GTX, I want to use the local debugging option
Win 7. Pro 64Bit
Dev Env.: VS2008 or VS2010
CUDA 4.0 & Parallel Nsight 2.0
NV Driver Vers.: 285.38
WPF is disabled
TDR is disabled
Windows runs in Basic mode (no aero)
Project Propertys: Cuda Runtime API -> GPU-> Generate GPU Debug Information -> Yes (-G0)
Firstly, you need to ensure that your display is driven by the Intel integrated graphics and not the NVIDIA GPU. This is because when you hit a breakpoint in CUDA code you are stalling the entire GPU, so if the same GPU was used for display then your system would lock up naturally.
Note that the hardware requirements for Parallel Nsight indicate you need two supported GPUs whereas you only have one, but if I understand correctly it's possible to use a non-Intel GPU for display (I haven't tried).
Assuming the above is working you should start by trying out the samples included with Parallel Nsight. You can find them in the Parallel Nsight menu group in the start menu.
CUDA Grid Launch has a wide variety of causes. This one is probably accessing an array beyond its allocated size. what in the x86 world is called a segmentation fault. i debug these by selectively commenting out parts of the kernel you are testing until the error goes away. (what we used to call wolf fence debugging). Another cause of grid launch failure is if the kernel is taking too long (1 or 2 seconds) to execute.
the reason the debugger isnt helping is that the debugger ONLY stops 1 thread in 1 block! your access error is coming before then. also you cant use the printf to find the bug as the output does not get returned in the event of a grid launch failure.
To add potential solution on top of the answers given already, one way to avoid the error is to run the NSight monitor with administrator right.
The answer for this is definitely using the correct driver for the installation of Parallel NSight. For the latest version (2.1 RC2, currently), this is driver version 285.86. For the current stable version 2.0, this is driver version 270.81, as another poster mentioned.