I need to fix leaks in a huge open-source library. For that I am using google-perftools, Now this library is linked in another big application, which can also have possibaly lots of memory leaks [ Finding leaks from an application is not my goal/job] so how can I ask google HEAPCHECKER to only get the memory leaks of library and not of application?
One approach I have tried is:-
I linked library with google-perftools lib and did not explicitly linked an application with it. and while running an application with HEAPCHECK enabled, It gives me this error
Check failed:
heap_profile->FindAlloc(test_str,
&size): our own new/delete not linked?
Please help me in finding solution to get the memory-leaks of only library.
PS. My platform is embedded linux and I am using gnu linker and G++ compiler.
Well, I found that it is not possible with google-heap-tools.
Related
I am currently doing some research on techniques about hooking mobile applications and came across some frameworks like Xposed (Android), Frida (Android and iOS) and Cycript (iOS).
The documentation about Xposed and Frida is fairly good explaining how exactly they are doing it. Xposed states to manipulate the binary starting the Zygote process and loading an additional JAR file that assists in hooking the methods. Frida documentation explains that it uses ptrace (in Linux environments) to attach to a process, allocating and populating a bootstrapper that loads a thread to launch a .so file containing the frida agent, in a nutshell, if I understood it correctly.
I couldn't find useful documentation about the strategy that Cycript pursues. I know that it is built on top of Cydia Substrate that does the actual hooking. I couldn't find details about how exactly Substrate accomplishes this either.
I further understand that on iOS the objective-c runtime enables runtime manipulation as it is runtime-oriented.
Does anybody know how exactly Cycript / Cydia Substrate works to hook/inject into applications?
Thanks in advance.
It figured out that is apparently working by adding the DYLD_INSERT_LIBRARIES into the program's launchd manifest and thereby every time the application is started it loads the malicious payload by loading the dynamic library.
Still, are there other techniques how to perform runtime hooking / manipulations on Android and iOS?
I am currently using Google Breakpad in my Linux app. I built breakpad by configure&make, I am linking /src/client/linux/libbreakpad_client.a and it works fine, dump is created in case of crash.
Now I would like to also use common/linux/http_upload functions to upload dump somewhere similar way as it is done in src/tools/linux/symupload/minidump_upload but I get undefined reference to google_breakpad::HTTPUpload::SendRequest...
How to proceed? Is is not built on Linux into some library? Linking libbreakpad_client.a and libbreakpad.a does not seem to be enough. Do I need to build it somehow separately? Thanks for help.
It requires src/common/linux/http_upload.cc to be included in (for example) libbreakpad_client.a, I added that line to Makefile.am to src_client_linux_libbreakpad_client_a_SOURCES section. It seems it is not built otherwise by any configure arguments or I missed it.
What is this and what is it purpose. I notice that when i compile my console apps in c++ is dynamically links it. I'm just curious what purpose this file serves and is it exploitable in the sense that if it has to be on every ones machine to run c code , is there some way for Microsoft or some other entity to exploit it for malicious ends.
That is the Standard C++ Library for native code, here you can read more about these libraries: http://msdn.microsoft.com/en-us/library/8kche8ah%28v=vs.90%29.aspx
I'd like to generate a flame graph for my node.js app. Unfortunately, my dev box is OSX (doesn't support utrace helpers, per the linked article) and my production box is CentOS (doesn't even have dtrace).
I've found some indication that something like SystemTap might be a dtrace alternative, but I've been unable to cobble together an effective working way to generate the appropriate stacks.out file to feed into stackvis.
Does anybody know of a decent tutorial on how to get this up and running? I'd prefer it on CentOS (so I can examine my production app) but OSX would also be sufficient.
From the latest google searches, people are unhappy with SystemTap on Centos, but here is an article http://dtrace.org/blogs/brendan/2012/03/17/linux-kernel-performance-flame-graphs/ that was referenced by someone's FlameGraph github project https://github.com/brendangregg/FlameGraph
I would say move towards the real solution, of getting dtrace installed rather than relying on the work around.
On Linux, the perf_events profiler can be used to sample stack traces, and has JIT symbol support. For node.js, you need to be running version 0.11.13 or higher, with the v8 option --perf-basic-prof. That option creates a /tmp/perf-PID.map file for symbol translation, which perf uses. Once you have perf profiling stack traces with JavaScript symbols, you can then create flame graphs using stackcollapse-perf.pl (from the FlameGraph repo) on the output of "perf script".
I wrote up the full instructions here: http://www.brendangregg.com/blog/2014-09-17/node-flame-graphs-on-linux.html
I'm trying to compile a statically linked binary with GCC and I'm getting warning messages like:
warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
I don't even know what getwnam_r does, but I assume it's getting called from inside some higher level API. I receive a similar message for gethostbyname.
Why would it not be possible to just statically link these functions in like every other function?
Function calls that need access to NSS or iconv need access will open other libs dynamically, since NSS needs plugins to work (the helper modules like pam_unix.so). When the NSS system dlopens these modules, there will be two conflicting versions of glibc - the one your program brought with it (statically compiled in), and the one dlopen()ed by NSS dependencies. Shit will happen.
This is why you can't build static programs using getpwnam_r and a few other functions.
AFAIK, it's not impossible to fully statically link an application.
The problem would be incompatibility with newer library versions which might be completely different. Say for example printf(). You can statically link it, but what if in a future that printf() implementation changes radically and this new implementation is not backward-compatible? Your appliction would be broken.
Please someone correct me if I'm wrong here.