I am implementing a memory tracker in my application so that further down the line, should I get any memory leaks I can switch this little guy on to find it.
All is great except that I am never passed the filename or the line number. Is there some flag I have to set using _CrtSetDbgFlag, or a preprocessor command?
After I ran the thing (bare-bones) it showed 26 allocations that were not cleaned up and I am pretty sure they are not me, but have no idea where they occurred.
Thanks in advance!
From the <crtdbg.h> header file:
#ifdef _CRTDBG_MAP_ALLOC
#define malloc(s) _malloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)
// etc...
#endif
Note how the redefinition now calls another version of malloc that has the file and line number that you are looking for. Clearly, to make this work you will have to #define _CRTDBG_MAP_ALLOC and #include crtdb.h. This is best done in your precompiled header file so that you can be reasonably sure that all of your code will be compiled with these macros in effect.
That still doesn't guarantee that you'll get this info. Your project might be using a .lib that was compiled without it. Another failure mode is DLLs that might be unloaded just before you generate the leak report. The file and line info for that DLL will be unloaded as well.
There's a fallback to diagnose those kind of trouble makers. The leak report has a line for the leak that starts with the block number, shown at the start inside curly braces. As long as that block number is stable between runs, you can force the debugger to break when the allocation is made. Put this code in your main method or whatever point in your code that executes early:
_crtBreakAlloc = 42; // Change the number
Related
Currently using to show debug output when in debug mode:
#ifdef _DEBUG
#define printX(...) Serial.printf( __VA_ARGS__ )
#else
#define printX(...) NULL
#endif
yet this still include the printX in the result code, and the parameters which have been applied still consume memory, cpu power, and stack size, so my question is:
is there a way to have a macro, which is not including the function, and "ignoring" all of it's calls in the source when in "release mode" and basically not compile anything with it ?
A macro is a not a function. It does not consume any memory, cpu power, or stack size. This is because macros operate entirely at compile time, and just act as a text replacing mechanism. When the program is run, there are no macros which are "called".
The macro
#define printX(...) NULL
replaces printX function call with all its arguments with plain NULL. This is a textual replacement that happens before a compiler is able to take a look at the code, so any nested calls inside printX, e.g.
printX(someExpensiveCall())
will also be completely eliminated.
In my programs I include a line that says:
#define DEBUG_MODE
and I use it anywhere I want to compile with (or without) debug mode:
#ifdef DEBUG_MODE
print here all the info I need for debug and certainly don't want in released binary.
#endif
Before releasing the final binary I comment out the definition line.
After some days of test I figured out that the runtime patching mechanism patch_functions.cc is not safe to use in a production environment.
It seems to work well in a VS2010 project except for HeapAlloc() and HeapFree() but cannot be used in a VS2015 project due to some unresolved problems Open Issues.
the windows readme describes this alternative way to use tcmalloc:
An alternative to all the above is to statically link your application
with libc, and then replace its malloc with tcmalloc. This allows you
to just build and link your program normally; the tcmalloc support
comes in a post-processing step. This is more reliable than the above
technique (which depends on run-time patching, which is inherently
fragile), though more work to set up. For details, see
https://groups.google.com/group/google-perftools/browse_thread/thread/41cd3710af85e57b
Unfortunately the provided lik is urechable, seems that google had closed the group.
Could someone explain me how to do this?
I assume it suggests to write your own malloc which uses tcmalloc.
So you have to define and link your own one (by creating or using an .c aka translation unit) and write something like this
#ifdef __cplusplus
extern "C" {
#endif
#include <stdlib.h>
void* malloc(size_t size) {
return tcmalloc(size);
}
//Also define a free if memory which has been allocated by tcmalloc
//needs to be freed by a special function
// Like
/*
void free(void* ptr) {
if (ptr) {
tcfree(ptr);
}
}
*/
#ifdef __cplusplus
}
#endif
Problem is: Depending on your building system or linker, it may nag about double symbols aka references. Then you have to somehow exclude libcs malloc, or change the libc by yourself.
I stumbled on this as well and believe I found a way to have it working.
First, in windows\config.h, you have to replace
#undef WIN32_OVERRIDE_ALLOCATORS
by
#define WIN32_OVERRIDE_ALLOCATORS
Then, and it's the most important thing, you have to make sure of two things:
windows\patch_functions.cc is not compiled and linked
windows\overridde_functions.cc is compiled and linked
At first, I omitted step 2 and got a barely functioning DLL where some memory allocations would get freed and overridden apparently at random.
In my case, making sure of both steps was just a matter of ensuring only windows\override_functions.cc is included in my libtcmalloc VS2017 project.
I am trying to use this code to allocate a slice of code to a independent section:
#ifdef _MSC_VER
#pragma section(".evil",execute)
#pragma code_seg(".evil")
#endif
#ifdef __GNUC__
static __attribute__((section (".evil")))
#elif defined _MSC_VER
static __declspec(allocate(".evil"))
#endif
void __invoke__start()
{//...
But that does not work and the compiler says
The __declspec( allocate()) syntax can be used for static data only.
I do this because I have to write some code to a new file ,and that file is a executable file.
Actually I can not find a way to get the exact address of a function in the memory when the program is running,if the program is compiled with MS VC++ debug mode
For a full example,please see this code : full example
Now, the above problem has been solved, but I still want to make it clear that if it is possible to put some code to a independent section. There's other benefit when it is possible for my work, after all.
When I link two object file (COFF format), how can I make sure different code from different obj file will be in different section?
Or is there another way to do this?
I am so sorry for my poor English.
you can find the memory address of the beginning of a function with inline assembler, then call a function to use the memory address, like:
void foo(){
__asm{
CALL 0h \\Put current address on top of stack
CALL myFunction \\Actually make a funciton call
}
...
}
int myFunction( int addrFromASM){
\\do something with addrFromASM+4, which will be where the rest of foo starts.
}
Apart from the fact that your code has some nice UB in it (you are assuming that the compiler will always put the functions in the order you except), what you want to do with the sections can be done by allocating a new section in the PE header that you write and putting your code there (see the paragraph on The Section Table, found here), you would need to set the BaseOfCode to this section as well and adjust NumberOfSections accordingly.
In terms of the funny address for functions, this because of Edit & Continue being on when compiling in debug mode, just turn it off in the project options and your addresses will be correct.
Whenever I exit my program it gives me this exception "0xC0000022: A process has requested access to an object, but has not been granted those access rights."
It breaks right at the end of a function called _lock_file in _file.c.
After trying to narrow down what the cause of the problem is I found out that it does not crash if I remove all fclose() function calls in my program then cleaning and rebuilding my program. Even if the function itself is never called it will still crash. Obviously this solution is not ideal.
When I tried to use fstream instead it produced a similar crash at the start of the program.
It's also worth mentioning that my program uses SDL.
Edit: Someone requested a minimal example and this is what I cam up with.
main.cpp
#include <stdlib.h>
#include <SDL.h>
/*...*/
#pragma comment(lib, "SDL.lib")
#pragma comment(lib, "SDLmain.lib")
/*...*/
int main( int argc, char **argv)
{
if(false)
fclose(NULL);
return 0;
}
draw.cpp
/*...*/
If I run this it will crash on exit just like I mentioned above. And yes the draw.cpp is completely commented out, but if I remove it from the project the program will run fine. All other files were removed from the project.
Edit2: In response to karlphillip I decided to double check if it is actually running and it seems that it is actually crashing at the start with this example.
Also it is a Win32 project.
Having a crash on exit usually means that the heap is corrupted during program execution. Try using a memory checker to find where. Try using _CrtDumpMemoryLeaks()
Are you using the same runtime library (Debug DLL, Debug, Release DLL, Release, etc.) for your main program as was used to build the SDL library? That can often (but not always) cause odd problems, and would be my first port of call when getting this sort of odd behaviour at runtime.
(If you get an LNK4098 warning when building, this is what it is trying to tell you, and you really need to fix it properly; the "solution" the text of the warning suggests is anything but.)
Another option is memory corruption. Consider running a debug build, and calling the following on startup:
_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG)|_CRTDBG_CHECK_ALWAYS_DF);
This activates more thorough heap checking. (You might have to go and make a cup of tea when your program runs with this switched on, if it allocates lots of stuff while it's running.) If then "crashes" in one of the memory allocation functions -- it's actually an assert, you can't always tell though -- then at some point between that call, and the previous call to a memory management function, something has overwritten some memory it should not have. And you can take it from there, to find out what.
-Edit: "_CRTDBG_REPORT_FLAG_DF", was probably intended to be "_CRTDBG_REPORT_FLAG".
Crashing on exit can also be caused by static variables destructing and accessing objects that have already been cleaned up.
Check you static objects and ensure their destructors are not causing the crash.
How do you know your application is being executed in the first place? Add a debug right after main() is called:
#include <stdlib.h>
#include <SDL.h>
/*...*/
#pragma comment(lib, "SDL.lib")
#pragma comment(lib, "SDLmain.lib")
/*...*/
int main( int argc, char **argv)
{
printf("dbg1\n");
if(false)
fclose(NULL);
printf("dbg2\n");
return 0;
}
What kind of project are you creating? Console, Win32 or something else?
I find this post very interesting.
I have the following code snippet:
#ifdef DO_LOG
#define log(p) record(p)
#else
#define log(p)
#endif
void record(char *data){
.....
.....
}
Now if I call log("hello world") in my code and DO_LOG isn't defined, will the line be compiled, in other words will it eat up the memory for the string "hello world"?
P.S. There are a lot of record calls in the program and it is memory sensitive, so is there any other way to conditionally compile so that it only depends on the #define DO_LOG?
This should be trivial to verify for yourself by inspecting the resulting binary.
I would say "no", since the expression totally goes away, the compiler will never see the string (it's removed by the preprocessor's macro expansion).
Since the preprocessor runs before the compiler, the line will not even exist when the compiler runs. So the answer is no, it does not use any memory at all.
No, it will not be in the binary. It will not even be compiled - the preprocessor will expand it into an empty string prior to the compilation, so the compiler will not even see it.
No. The preprocessor is executed prior to compilation, and so the code will never even be seen. I would like to add, though, that if you are interested in adding logging to your C++ application, you might want to use the Log4Cxx library. It uses similar macros which you can completely elide from your application, but when logging is enabled, it supports several different levels of logging (based on importance/severity) as well as multiple different "appenders" to which to send logging output (e.g. syslog, console, files, network I/O, etc.).
The full API documentation may be found at Log4Cxx API docs. Also, if you have any Java developers on board who have used Log4J, they should feel right at home with Log4Cxx (and convince you to use it).