I would like to know what the current sbrk() limit is to debug a SEGV I'm having a hard time with. My code looks good and works in most cases (only one case out of quite many breaks with SEGV.)
I'm thinking it may be in link with the fact that in this case we use a multi-threaded application, but I just can't pinpoint the problem right now. I'd like to compare the SEGV address with the sbrk() limit to see how off the address is. I'm thinking it could be a mmap() or some similar address which gets removed under my feet.
If the process still has a valid stack, you can call the sbrk function from libc:
(gdb) print ((void *(*) (unsigned long)) sbrk)(0)
$1 = (void *) 0x55555580e000
The cast is not necessary if GDB was able to load debugging information for libc.
(This may not work for statically linked binaries if sbrk is not linked into the program at all.)
In principle it works with any function for which GDB can find a symbol. But whether it's safe to call a particular function from GDB depends on where exactly the program has stopped (e.g., calling malloc from within malloc is usually a bad idea).
Related
My boss wants me to see if I can write a "one button memory leak checker" in our Java client for our testers (since I then would have to spend less time myself running our full manual test suite under a profiler; we don't have an automated test-suite).
I have found something that is pretty close to what I need: Heap Walker I had to modify it slightly to compile in VS in Windows (I think it was made for GCC under Mac). But when I run it, the JVM crashes.
I'd like to get a native stack-trace to see at least where it crashes, and if I can find out what happens, but idk how. I have built a "debug" DLL, but I still get no stack-trace. Neither on the console, nor in the "hs_err_pidXXXX.log" file generated by the JVM.
I haven't done any C/C++ in about 15 years; I can still about "guess" what the code does, but I forgotten how the debugging goes (beyond "printf everywhere" ...), and I never had to debug native code in the JVM. So far, Google was no help; I'm probably using the wrong terms to search.
JVM usually reports native stack trace in the crash dump. If there is no stack trace in hs_err_pid.log, it means JVM could not obtain the last frame from PC register, typically because it pointed to unreadable address.
For example, this can happen if a native code dereferences null function pointer:
void (*func)() = 0;
func();
In this case PC will be zero, and JVM won't print the trace. But you can still find caller PC from the stack, because the return address is typically pushed onto the stack before a call. Here is how to find it in hs_err_pid.log:
Top of Stack: (sp=0x0000000002e2f438)
0x0000000002e2f438: 00007ffcf03f1030 00007ffcf041d000
^^^^^^^^^^^^^^^^
the return address (the address after the last valid instruction)
Then you can find this address in Dynamic libraries section and calculate the offset from the beginning of dll.
Dynamic libraries:
...
0x00007ffcf03f0000 - 0x00007ffcf0426000 C:\Java\Test\crash.dll
^^^^^^^^^^^^^^^^^^
offset = 0x00007ffcf03f1030 - 0x00007ffcf03f0000 = 0x1030
Use disassembler (e.g. Visual Studio's dumpbin) to decode the offest into the particular function / instruction in the code.
You can also attach Visual Studio debugger to the JVM when it crashes. In order to do so, you should run Java with -XX:+ShowMessageBoxOnError. The following window will invite you to connect the debugger:
At first, I'm a newbie on c++ and debuging. I use CreateProcess api with DEBUG_ONLY_THIS_PROCESS parameter, then wait for CREATE_PROCESS_DEBUG_EVENT. When recived, i check for the Eip register to get the address of the point. And i tought that this point is the Main function's address.
To verify this idea i used ollydbg to see the starting address of the exe. But it wasn't same with mine. The one i found with debug apis is 0x77a364d8, but olly says that it's 0x00401000. Then i didn't stop and checked for the address 0x77a364d8 in olly. I found the address and set a breakpoint there.
Then I reloaded the olly and saw that olly firstly goes 0x77a364d8 address and loades the process and then goes to the 0x00401000 address and waits there. 0x77a364d8 address points some ntdll functions to load process to memory as i see.
If it's true, how can i get the 0x00401000 address by code( c++, i'm a newbie and please cross the t's :) ), and is it the Main function's address or what?
After you receive the CREATE_PROCESS_DEBUG_EVENT you should be able to access the CREATE_PROCESS_DEBUG_INFO member of the union. It has a member called lpStartAddress.
Your debugging event loop should look something like:
DWORD dwContinueDebugStatus = DBG_CONTINUE;
while(dwContinueDebugStatus)
{
DEBUG_EVENT debugEvt;
WaitForDebugEvent(&debugEvt, INFINITE);
switch(debugEvt.dwDebugEventCode)
{
case CREATE_PROCESS_DEBUG_EVENT:
// Grab the main thread entry point.
LPTHREAD_START_ROUTINE exentry = debugEvt.u.CreateProcessInfo.lpStartAddress;
break;
/* Handle the rest of your debug events here. */
}
ContinueDebugEvent(debugEvt.dwProcessId, debugEvt.dwThreadId, dwContinueDebugStatus);
}
Edit:
A couple things I forgot to mention...
Getting the entry point by any of these means will likely be the CRT function that calls your main(). There isn't a reliable way to get the main() without symbol lookups in using dbghelp.dll.
Also, the book Debugging Applications by John Robbins has a chapter about creating a small debugger with some example code. It is probably the best documentation/example I've found (but I wish it were better). It can be had pretty cheap so it might be worth looking at.
The entry point will not (at least normally) be the same as main. The signature for the entry point is void entrypoint(void);. That has to retrieve the command line, parse it into individual arguments, etc., in preparation for calling main (and there's an entirely separate one that retrieves the rather different "stuff" necessary before calling WinMain in a GUI program).
If you want the actual address of main, you might want to at least try using SymFromName for the names _main and/or _wmain (or, if you might be dealing with a GUI program, WinMain/wWinmain) to get to code that's really part of the target program instead of something from a library module almost nobody has ever even seen.
This is all from memory, so it might contain a few mistakes.
In order to find the entry point address of the EXE in a new process, you need to read this process's PEB field ImageBaseAddress. The PEB is always at a fixed address, but it depends on if your EXE is 32 or 64-bit, which you'll have to determine beforehand (there is a 32-bit PEB for WOW64 but I think it may not be initialized yet at that point).
Note that you can't just fetch this from the EXE because it might be relocated due to ASLR. Once you have this, you can read PE header of the EXE using ReadProcessMemory and get the AddressOfEntryPoint field from the IMAGE_OPTIONAL_HEADER struct. It's an RVA so add it to the base address found earlier, and voila, you have your entry point address.
I'm on amd64 architecture. The following code gets rejected by the g++ compiler at the "if" statement:
void * newmem=malloc(n);
if(newmem==0xefbeaddeefbeadde){
with the error message:
error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
I can't seem to find the magic incantation needed to get it going (and I don't want to use -fpermissive). Any help appreciated.
Background:
I'm hunting an ugly bug which crashes my program while requesting memory in some STL new operation (at least gdb told me that). Thinking it could be some memory overrun of one of the allocated memory chunks being, by bad luck, adjacent to memory used by the OS to manage memory lists of my program, I quickly overrode new(), new plus their delete counterparts with own routines that added memory fencing; and while the application still crashes (all fences intact (sigh)), gdb now told me this:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000604f5e in construct (__val=..., __p=0xefbeaddeefbeadde, this=<optimized out>)
at /usr/include/c++/4.6/ext/new_allocator.h:108
108 { ::new((void *)__p) _Tp(__val); }
I noted that the pointer __p has as value the pointer representation of the value I used for one of my memory fences (0xdeadbeef), hence my wish to catch this earlier in my new() to try and dump out some more complex values in my program.
Additional note: the function where it crashes runs flawlessly a couple of million times before it crashes (intermixed with dozens of other routines which all also run a couple of thousand to million times), using valgrind does not seem like an option atm because it takes 6hrs and 11 Gb before my program crashes.
One of them is an integer, and the other a pointer. Perhaps an ugly cast would do
if(newmem==(void*)0xefbeaddeefbeadde){
For your question: you have 2 options - cast the pointer to 64bit number or cast the number to void*
For the background: as this takes too long, it could be a memory leak. So, try valgrind - no need to wait for crash, just run your program through valgrind and use the appropriate options. valgrind could help you to catch undefined behavior, too.
Another thing - compile your program with -O0 optimization level and with max level of debug symbols - -ggdb3. Also, if your executable does not generate a core dump, when this error occurs, make it generate. Then leave it working, while you're trying different approaches to catch the error.
In case you don't succeed, you'll at least have a (hopefully) nice core dump, that you can examine with gdb your_exe the_core_dump. Then, watch the core frame by frame, watch the variables, etc.
If it's not a memory leak, it could be a memory corruption somewhere, undefined behavior or something like this. If a good core dump is generated, you'll probably catch the error. Or, at least, it could give you useful information about the case.
Another thing, that could be useful, if you generate a core dump (no matter if it's a good or a bad one) - the size of the dump. If it's too large (the definition of "large" this depends on your program), then you most probably have a memory leak (it could be some kind of cross-reference issue, if you use smart pointers and if so - valgrind will not catch it)
That probably won't work that way. Next time when your program runs, malloc may never return that value. There is something else you must do, rather than just checking on the return value of new!
This question already has answers here:
Closed 13 years ago.
Possible Duplicates:
How can I get the size of an array from a pointer in C?
Is there any way to determine the size of a C++ array programmatically? And if not, why?
I get a pointer to a chunk of allocated memory out of a C style function.
Now, it would be really interesting for debugging purposes to know how
big the allocated memory block that this pointer points is.
Is there anything more elegant than provoking an exception by blindly running over its boundaries?
Thanks in advance,
Andreas
EDIT:
I use VC++2005 on Windows, and GCC 4.3 on Linux
EDIT2:
I have _msize under VC++2005
Unfortunately it results in an exception in debug mode....
EDIT3:
Well. I have tried the way I described above with the exception, and it works.
At least while I am debugging and ensuring that immediately after the call
to the library exits I run over the buffer boundaries. Works like a charm.
It just isn't elegant and in no way usable in production code.
It's not standard but if your library has a msize() function that will give you the size.
A common solution is to wrap malloc with your own function that logs each request along with the size and resulting memory range, in the release build you can switch back to the 'real' malloc.
If you don't mind sleazy violence for the sake of debugging, you can #define macros to hook calls to malloc and free and pad the first 4 bytes with the size.
To the tune of
void *malloc_hook(size_t size) {
size += sizeof (size_t);
void *ptr = malloc(size);
*(size_t *) ptr = size;
return ((size_t *) ptr) + 1;
}
void free_hook (void *ptr) {
ptr = (void *) (((size_t *) ptr) - 1);
free(ptr);
}
size_t report_size(ptr) {
return * (((size_t *) ptr) - 1);
}
then
#define malloc(x) malloc_hook(x)
and so on
The C runtime library does not provide such a function. Furthermore, deliberately provoking an exception will not tell you how big the block is either.
Usually the way this problem is solved in C is to maintain a separate variable which keeps track of the size of the allocated block. Of course, this is sometimes inconvenient but there's generally no other way to know.
Your C runtime library may provide some heap debug functions that can query allocated blocks (after all, free() needs to know how big the block is), but any of this sort of thing will be nonportable.
With gcc and the GNU linker, you can easily wrap malloc
#include <stdlib.h>
#include <stdio.h>
void* __real_malloc(size_t sz);
void* __wrap_malloc(size_t sz)
{
void *ptr;
ptr = __real_malloc(sz);
fprintf(stderr, "malloc of size %d yields pointer %p\n", sz, ptr);
/* if you wish to save the pointer and the size to a data structure,
then remember to add wrap code for calloc, realloc and free */
return ptr;
}
int main()
{
char *x;
x = malloc(103);
return 0;
}
and compile with
gcc a.c -o a -Wall -Werror -Wl,--wrap=malloc
(Of course, this will also work with c++ code compiled with g++, and with the new operator (through it's mangled name) if you wish.)
In effect, the statically/dynamically loaded library will also use your __wrap_malloc.
No, and you can't rely on an exception when overrunning its boundaries, unless it's in your implementation's documentation. It's part of the stuff you really don't need to know about to write programs. Dig into your compiler's documentation or source code if you really want to know.
There is no standard C function to do this. Depending on your platform, there may be a non-portable method - what OS and C library are you using?
Note that provoking an exception is unreliable - there may be other allocations immediately after the chunk you have, and so you might not get an exception until long after you exceed the limits of your current chunk.
Memory checkers like Valgrind's memcheck and Google's TCMalloc (the heap checker part) keep track of this sort of thing.
You can use TCMalloc to dump a heap profile that shows where things got allocated, or you can just have it check to make sure your heap is the same at two points in program execution using SameHeap().
Partial solution: on Windows you can use the PageHeap to catch a memory access outside the allocated block.
PageHeap is an alternate memory manager present in the Windows kernel (in the NT varieties but nobody should be using any other version nowadays). It takes every allocation in a process and returns a memory block that has its end aligned with the end of a memory page, then it makes the following page unaccessible (no read, no write access). If the program tries to read or write past the end of the block, you'll get an access violation you can catch with your favorite debugger.
How to get it: Download and install the package Debugging Tools for Windows from Microsoft: http://www.microsoft.com/whdc/devtools/debugging/default.mspx
then launch the GFlags utility, go to the 3rd tab and enter the name of your executable, then Hit the key. Check the PageHeap checkbox, click OK and you're good to go.
The last thing: when you're done with debugging, don't ever forget to launch GFlags again, and disable PageHeap for the application. GFlags enters this setting into the Registry (under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\), so it is persistent, even across reboots.
Also, be aware that using PageHeap can increase the memory needs of your application tremendously.
The way to do what you want is to BE the allocator. If you filter all requests, and then record them for debugging purposes, then you can find out what you want when the memory is free'd.
Additionally, you can check at the end of the program to see if all allocated blocks were freed, and if not, list them. An ambitious library of this sort could even take FUNCTION and LINE parameters via a macro to let you know exactly where you are leaking memory.
Finally, Microsoft's MSVCRT provides a a debuggable heap that has many useful tools that you can use in your debug version to find memory problems: http://msdn.microsoft.com/en-us/library/bebs9zyz.aspx
On Linux, you can use valgrind to find many errors. http://valgrind.org/
I'm running my C++ program in gdb. I'm not real experienced with gdb, but I'm getting messages like:
warning: HEAP[test.exe]:
warning: Heap block at 064EA560 modified at 064EA569 past requested size of 1
How can I track down where this is happening at? Viewing the memory doesn't give me any clues.
Thanks!
So you're busting your heap. Here's a nice GDB tutorial to keep in mind.
My normal practice is to set a break in known good part of the code. Once it gets there step through until you error out. Normally you can determine the problem that way.
Because you're getting a heap error I'd assume it has to do with something you're putting on the heap so pay special attention to variables (I think you can use print in GDB to determine it's memory address and that may be able to sync you with where your erroring out). You should also remember that entering functions and returning from functions play with the heap so they may be where your problem lies (especially if you messed your heap before returning from a function).
You can probably use a feature called a "watch point". This is like a break point but the debugger stops when the memory is modified.
I gave a rough idea on how to use this in an answer to a different question.
If you can use other tools, I highly recommend trying out Valgrind. It is an instrumentation framework, that can run your code in a manner that allows it to, typically, stop at the exact instruction that causes the error. Heap errors are usually easy to find, this way.
One thing you can try, as this is the same sort of thing as the standard libc, with the MALLOC_CHECK_ envronment variable configured (man libc).
If you keep from exiting gdb (if your application quit's, just use "r" to re-run it), you can setup a memory breakpoint at that address, "hbreak 0x64EA569", also use "help hbreak" to configure condition's or other breakpoitn enable/disable options to prevent excessively entering that breakpoint....
You can just configure a log file, set log ... setup a stack trace on every break, "display/bt -4", then hit r, and just hold down the enter key and let it scroll by
"or use c ## to continue x times... etc..", eventually you will see that same assertion, then you will now have (due to the display/bt) a stacktrace which you can corolate to what code was modifying on that address...
I had similar problem when I was trying to realloc array of pointers to my structures, but instead I was reallocating as array of ints (because I got the code from tutorial and forgot to change it). The compiler wasnt correcting me because it cannot be checked whats in size argument.
My variable was:
itemsetList_t ** iteration_isets;
So in realloc instead of having:
iteration_isets = realloc(iteration_isets, sizeof(itemsetList_t *) * max_elem);
I had:
iteration_isets = realloc(iteration_isets, sizeof(int) * max_elem);
And this caused my heap problem.