I am working on Visual Studio and I see that in our code(huge code base, with complex business use cases) that in a flow we are not freeing memory of a pointer that comes to the function. I was expecting that the memory would be freed there.
Is there a way I can figure out if that memory address(I know the address since it came to the function) has been freed or still owner by the process?
I tried "HeapMemView" and "RamMap". To test those I just created a pointer and assigned memory and tried viewing that using those viewers. The code I wrote was,
char *a=new char[1000];
char str[1000];
sprintf(str,"Address : %p",a);
MessageBox(0, str, "MessageBox", MB_OK);
and I try to see the address value printed using the tools above but I am not able to see the addresses.
Am I doing something wrong? Or is there a different way to do this?
You can use an external tool such as Purify in order to analyze your memory leaks.
The other technique under Visual Studio would be to use the CRT Debugging techniques in order to trace memory allocation/deallocation.
Please have a look on below link:
CRT Debugging techniques
Related
I am in the process of debugging a "corrupted double-linked list" crash. I have seen the source and understand the chunk struct and the fd/bk pointers, etc, so I think I know why this crash has occurred. I am now trying to fix it and I have a couple of questions.
Question #1: where (with respect to the pointer returned from malloc) is the malloc_chunks struct maintained? Are they before the memory block or after it?
Question #2: the malloc_chunks for allocated memory are different from the malloc_chunks for unallocated memory. It appears (??) that the allocated buffer case does not have the fd/bk pointers. Is this correct?
Question #3: what is the recommended approach to debug this type of error? I am assuming that I should put a break point for the malloc_chunks so I can break on when the struct is overwritten. But I am not sure how to access those malloc structs so I can set a break point in gdb.
Any suggestions on how to proceed would be very appreciated.
Thanks,
-Andres
what is the recommended approach to debug this type of error?
The usual way is not to peek into GLIBC internals, but to use a tool like Valgrind or AddressSanitizer, either of which is likely to point you straight at the problem.
Update:
Valgrind crashes ...
You should try building the latest Valgrind version from source, and if that still crashes, report the crash to Valgrind developers.
Chances are the Valgrind problem is already fixed, and building new Valgrind and testing your program with it will still be faster than trying to debug GLIBC internals (heap corruption bugs are notoriously difficult to find by program inspection or debugging).
AddressSanitizer, I thought it was a clang only tool -- I do not think it is available for linux.
Two points:
Clang works just fine on Linux, I use it almost every day,
Recent GCC versions have an equivalent -fsanitize=address option.
There are ways to debug heap overruns without valgrind.
One way is to use a malloc debug library such as Electric Fence. It will make your rogram crash exactly at the moment of accessing an illegal address in the heap.
The other way is to use built-in debug capabilities of GNU malloc. See man mcheck. If you call mcheck_pedantic before the first call to malloc, then every memory block is checked at every allocation. This is very slow but does allow you to isolate the fault.
For an embedded ARM system running in-field there is a need to retrieve relevant debug information when a user-space application crash occurs. Such information will be stored in a non-volatile memory so it could be retreived at a later time. All such information must be stored during runtime, and cannot use third-party applications due to memory consumption concerns.
So far I have thought of following:
Signal ID and corresponding PC / memory addresses in case a kernel SIG occurs;
Process ID;
What other information do you think it's relevant in order to indentify the causing problem and be able to do a fast debug afterwards?
Thank you!
Usually, to be able to understand an issue, you'll need every register (from r0 to r15), the CPSR, and the top of the stack (to be able to determine what happened before the crash). Please also note that, when your program is interrupt for any invalid operation (jump to invalid address, ...), the processor goes to an exception mode, while you need to dump the registers and stack in the context of your process.
To be able to investigate, using those data, you also must keep the ELF files (with debug information, if possible) from your build, to be able to interpret the content of your registers and stack.
In the end, the more information you keep, the easier the debug is, but it may be expensive to keep every memory sections used by your program at the time of the failure (as a matter of fact, I've never done this).
In postmortem analysis, you will face some limits :
Dynamically linked libraries : if your crash occurs in a dynamically loaded and linked code, you will also need the lib binary you are using on your target.
Memory corruption : memory corruption usually results in the call of random data as code. On ARM with linux, this will probably lead to a segfault, as you can't go to an other process memory area, and as your data will probably be marked as "never execute", nevertheless, when the crash happens, you may have already corrupted the data that could have allow you to identify the source of the corruption. Postmortem analysis isn't always able to identify the failure cause.
I've got this game server that whether i download the pre-compiled binary or compile the source code myself just leaks until i have to reboot or enter a BSOD. I'm not super keen on C++ just currently classes for my degree but i can look at the code and understand whats going on. I'm just not 'fluent'.
Specifically looking at the resource monitor the modified memory type just fills and fills constantly by about 3-5MB per 5 seconds
is there anything i can do about this?
There is tool which is helpful for finding memory leaks: http://valgrind.org/
If you have ever ever heard about a tool called valgrind you can run your C++ code in valgrind to see exactly where the leakages are.
http://valgrind.org/
Greetings all,
I'm the developer of a rather large C# Windows Explorer extension. As you can imagine, there is a lot of P/Invoke involved, and unfortunately, I've confirmed that it's leaking unmanaged memory somewhere. However, I'm coming up empty as to how to find the leak. I tried following this helpful guide, which says to use WinDBG. But, when I try to use !heap, it won't let me because I don't have the .PDB files for explorer.exe (and the public symbol files aren't sufficient, apparently).
Help?
I've used many time UMDH with very good results. The guide you mentioned describing WinDbg uses the same method as UMDH, based on ability of debug heap to record stack traces for all allocations. The only difference is that UMDH does it automated -- you simply run umdh from command line and it creates snapshot of all current allocations. Normally you to repeate the snapshots two or more times, then you calculate 'delta' between two snapshots (also using umdh.exe). The information on the 'delta' file gives you all new allocations that happen between your snapshots, sorted by the allocation size.
UMDH also needs symbols. You will need at least symbols for ntdll.dll (heap implementation lives there). Public symbols available on public symbols from http://msdl.microsoft.com/download/symbols will work fine.
Make sure you are using correct bitness of the umdh.exe. Explorer.exe is 64 bit on 64 bit OS, so if your OS is 64 bit you need to use 64 bit umdh.exe -- i.e. download appropriate bitness of Windows debugging tools.
my j2me application shows out of memory exception in JBLEND. It work fine in JBED. By monitoring the memory, I realized that the document.parse(xmlParser) method consumes a lot of memory. I think the reason for the excption is memory is not freeing after parsing xml. is it right??? How can i solve the problem???
Whatever document.parse(xmlParser) returns, you should dereference it as soon a you don't need it anymore, i.e. you should set fields pointing to the returned object to null (or unset indirect references).
I've never used JBLEND or JBED, but the Wireless Toolkit respectively JaveME SDK also has a nice memory profiler which helps you track down memory and object reference problems.