I'm looking for official way in Contiki-NG for exclude all debug traces from code (security, code size, release version of application).
I have used extra definition in my Makefile
-DLOG_CONF_OUTPUT="(void)(0);" -Wno-unused-value
and code size is reduced but I should add -Wno-unused-value for avoid multiple warnings.
What can be better way to replace LOG_CONF_OUTPUT with something else ?
Regards,
Eugene
Related
One of our application (windows form application C++, MSVS 2010 )crashes after few minutes of usage. Task manager tells that the memory usage grows to 60% of total system RAM in just few seconds of the run.
I used Intel inspector to get any idea of memory leaks. I was expecting I will get a a list of functions that are creating problem. But what I got is only the dlls as can be seen in the following screenshot.
The application is using a couple of third party libraries such as those starting with Pv, OpenCv cdio, CAIO etc. As you can see the last one is an opencv library, and is occupying close to 400MB. (How is this possible ? )
Also the right panel shows different types of leaks which have occurred.
I want to pin point the memory leak code and correct it. What should be my strategy, what functions should I start looking into? Why the inspector is not giving me correct source code and just giving me dlls? I am sure dlls are perfect as these are used by millions of people.
Please advice,
Thanks
Update
I think I have done something wrong in various compiler setting while generating the exe. .
As can be seen above, no symbol information is loaded. That was the reason I was unable to get the source code where memory leaks were happening. Pressing F1 reaches me to the following instructions:
Troubleshooting No Symbolic Information Symptoms
In the Sources window, the Intel Inspector displays no source code for any code locations in the problem set.
Details Intel Inspector cannot display source code for viewing and editing unless the application has symbols available.
If the Intel Inspector detects no symbols for a location, it sets the call stack and code pane to the first location where it can find symbols.
If the Intel Inspector cannot find any location in the call stack with symbols, it provides the module name and relative virtual address (RVA) for the location.
Possible Correction Strategies
1- When you compile and link an application on Windows* systems:
a) Enable the debug information compiler option.
b) Set the linker option to generate debug information.
2- Configure the project to search non-standard directories.
3- Copy the symbol files, such as *.pdb files, to a location where the Intel Inspector can find them.
So now I am focusing on the above correction strategies. My latest question are:
1- how do I set the above three strategies in MSVS 2010.
2- Do I need to use debgug exe or a release exe while using Intel inspector ?
If this is your source code, and you are sure your code is causing the leaks, you can use Visual Leak Detector.
You just need very minimal changes in project - I would say just #include<vld.h> (which you can make conditional). It will report all memory leaks on Debug Output window. This differs from VC++ standard leaking staticitics - it shows where memory was allocated.
Probally it couldn't load symbols for some module / modules and thus the information is a bit incorrect. Is symbol file (like opencv_core240.pdb) opencv_core240.dll available? Check it!
Also I would suggest to try another memory leak detectors to compare their results to each other.
In general when using Inspector the recommendation is to use a debug build of the code. Release builds may optimize away some important pieces of code.
You can also enable just debugging symbols in a release build, which is important when using Amplifier and Advisor. You can do this by going to Project -> [project name] properties... -> Linker -> Debugging -> Generate Debug Info -> Yes and Project->[project name] properties...->C/C++->General->Debug Information Format -> Program Database. Even if you are in debug configuration make sure these settings are set correctly, because they may have been accidentally modified.
WRT what you are seeing in the report:
OpenCV (and others) isn't occupying 350MB, rather there has been a leak of that size (which means the last pointer to dynamically allocated memory was overwritten without releasing that memory). Is it possible that you're misusing the library APIs?
Also, you may find it useful to look at the call stack at the location of the leak. You will possibly find the API leading to the memory leak which can help you pinpoint the issue.
I am trying to create a way to transfer the debug information of a C++ project to a remote location for testing. In the current development cycle, small changes to the code require the entire binary (100s MB in size and mostly debug info) to be transferred.
Currently my approach to addressing this is by splitting the debugging information from the object files (the size of which without the debugging info is manageable on my connection) using -gsplit-dwarf and then diffing the debug files against a copy of the build currently on the remote box.
The aim is to have a set of patches for the debug files of a project so that new code can be debugged at a remote location. The connection between the remote location and the local machine is slow and so minimization of the size of the patches is paramount but it should also be balanced with the run time of the tool. I have looked into bsdiff and xdelta as potential solutions and have run into a conundrum where xdetla is fast but too large and bsdiff is perfect in terms of size but the run time and memory requirements are a little higher than I would like it to be.
Is there a tool or approach I am missing or am I just going about this the wrong way? Some alternative to bsdiff and xdelta perhaps? I know that a tool like gbdserver won't work in this situation because of some of the requirements we have with the actual debugging. Could some alteration of bsdiff help the performance? And indeed if the approach I'm using is sound, what would be a good way to keep a copy of the build on the remote machine around to diff against.
The simplest way is to use "strip" to copy the debuginfo into a separate ".debug" file, and then use "strip" again to remove the debug info from the executable that you will deploy. The "strip" manual explains how to do this, look for the "--only-keep-debug" option.
After you do this, you can tell gdb about the separate debug info in various ways. The very best way is to use the "build-id" feature. This is what modern Linux distros do. However there are other ways as well. There's a whole section in the gdb manual about separate debug files.
The key point here is that you can start gdb on the stripped executable and it will find the separate debug info automatically. This data can all be local, so you won't need to deploy the debug info.
If you still care about shrinking debug info even when this is done, you can look at the "dwz" tool. This is a DWARF compressor. However this usually only matters if you plan to ship the debug info somewhere -- distros use it to make it easier to download debug info, but ordinary users won't really see the need.
I would appreciate some help concerning a good way to debug invalid memory accesses on Windows. Being a Linux developer, I am a big fan of Valgrind. Even Duma and eFence are very efficient tools. But on Windows I am totally lost (WinXP/VS2008). I tried a lot of tools, tried to link my program against duma with no luck.
Here are the symptoms for the bug I am having:
Crash in Release mode on some specific configurations (only the size of my data changes)
When it doesn't crash in Release mode, the name of the test in the report is replaced by random characters. (I am using Boost.Test)
Nothing in Debug mode, everything goes well
This definitely sounds like a invalid write/read somewhere, but debugging in Release mode is impossible, I need to reproduce the crash in Debug mode. Redefining the new operator and try to imitate the behavior of eFence/Duma was my best bet, but I am having troubles overriding it.
So far I tried:
Dr.Memory
GFlags
AppVerifier
Duma (cannot override malloc/etc..)
I'd be more than thankful if someone could give me a tip there because it's been a while since I am trying to resolve this issue.
Thanks in advance.
I have a corruption memory heap with my application. I would like to use Application Verifier in order to find the bug.
I have some difficulties to find a tutorial on how use Application Verifier.
One of the first question I'm wondering is should I use my application in DEBUG or RELEASE mode ?
Thanks
Typically, in debug mode with a debugger attached will be your first stop. This provides full run-time checks, more validation, and more accurate information on what is going wrong. Application Verifier can also signal the debugger to break and will output error information, so having a debugger attached is very useful.
After that, as Simon Richter noted, you'll want to run most of it again in release. Release builds typically don't have the same checks and don't watch for errors, so things are very likely to surface that weren't an issue in the debug build. There is some use for a sort of manual-debug or hybrid build, where you perform some of the checks and logging to make sure things don't go too far afield.
To use Application Verifier, you really just need to start it, add an application and enable to desired tests. When you run, it will create a log and send messages/breaks to a debugger if one is around.
With the necessary experience in debugging, "Both" would be the right answer, as the differences between Debug and Release builds also give good hints about the source of the problem.
If you do not want to dive that deep into the inner workings of the compiler, then use the Debug version if the error appears there reliably.
usually debug versions run the application verifier to find the bugs in the app.
Here's the scenario. I'm debugging my own app (C/C++) which is using some library developed by another team in the company. An assertion fails when my code generates some edge case. Its a pain because the assertion is not formulated correctly so the library function is working OK but I get all these interruptions where I just have to continue (lots as its in a loop) so I can get to the stuff I'm actually interested in. I have to use the debug version of the library when debugging for other reasons. The other team wont fix this till next release (hey, it works on our machine).
Can I tell the debugger to ignore the breakpoints asserted by this section of code (i.e. can it auto-continue for me).
If the code is triggering breakpoints on its own (by __debugbreak or int 3), you cannot use conditional breakpoints, as the breakpoints are not know to Visual Studio at all. However, you may be able to disable any such breakpoints you are not interested in by modifying the code from the debugger. Probably not what you want, because you need to repeat this in each debugging session, however still may be better than nothing. For more information read How to disable a programmatical breakpoint / assert?.
There's no good way to automatically ignore ASSERT() failures in a debug library. If that's the one you have to use, you're just going to have to convince the other team that this needs fixed now, or if you have the source for this library, you could fix or remove the assertions yourself just to get your work done in the meantime.
You can add an exception handler around the call(s) to the library, catch the EXCEPTION_BREAKPOINT exception and do nothing.
Example 2 in the following link seems to be what you want to do:
http://msdn.microsoft.com/en-us/library/ms681409(VS.85).aspx
You can use conditional breakpoints. Some links:
http://support.microsoft.com/kb/308469
http://dotnettipoftheday.org/tips/conditional_breakpoint.aspx