I am trying to find a memory leak in a C library loaded by the JVM. Is it possible to configure valgrind to only do leak checks and none of the other checks. I ask because the JVM itself has a massive amount of memory errors detected by valgrind which I am not interested in.
I have attempted suppression but it seems like the JVM just keeps coming up with new errors.
Use the following option:
--undef-value-errors=no --show-mismatched-frees=no
Related
How can I determine where some function called in debug state? I'm in stuck with EXC_I386_GPFLT error hence I do not expect invocation such function with my test case.
You can try new Xcode 7 feature called Address Sanitizer.
In Xcode go to Product -> Scheme -> Edit Scheme, select Run, open Diagnostics tab and check Enable Address Sanitizer.
Then Product -> Clean project and run it again.
Objective-C and C code is susceptible to memory corruption issues such
as stack and heap buffer overruns and use-after-free issues. When
these memory violations occur, your app can crash unpredictably or
display odd behavior. Memory corruption issues are difficult to track
down because the crashes and odd behavior are often hard to reproduce,
and the cause can be far from the origin of the problem.
You enable the address sanitizer in the build scheme. Once enabled,
added instrumentation is built into the app to catch memory violations
immediately, enabling you to inspect the problem right at the place
where it occurs. Other diagnostic information is provided as well,
such as the relationship between the faulty address and a valid object
on the heap and allocation/deallocation information, which helps you
pinpoint and fix the problem quickly. The address sanitizer is
efficient—fast enough to be used regularly as well as with interactive
applications. It is supported in OS X, in the Simulator, and on iOS
devices.
New features in Xcode 7
When I run a code in OMNeT++ (eclipse based IDE), the simulation crashes after certain number of events. So to check for a memory leak, I used VALGRIND. When I run the code using this valgrind profiler, my simulation runs perfectly fine. I don't know the reason for this peculiar behavior. Can someone explain the reason behind this ?
Probably a 'heisenbug". I.e. an issue that changes its behavior if you try to examine it. It could be an uninitialized variable or other obscure bug that did not surface if the program starts with a different memory layout (i.e. under valgrind).
I would still look into the valgring logs, even if the crash does not occur as the logs may cotain some hints.
Well, that question may sound silly, but...
When I run my app in analyze mode or with instruments I get no possible (analyze mode) or memory (instruments) leaks.
Does it mean that my app is 100% memory leaks free ?
No. For one thing, you'd have to run every possible execution path/state sequence in your app to definitively say that there are no leaks by simple testing. More importantly, true memory leaks, where you don't release memory but no longer have a reference to it are all the leaks instrument is able to detect.
However, those are not the only similar problem you can create. You can also easily not discard data that you no longer actually need, causing memory to build up. This isn't a true leak, as you still have a reference to the data in question, it's just that you haven't released it and gotten rid of your reference to it.
You can still find this kind of problem using the allocations instrument. It won't explicitly flag problems, but it will allow you to see if you're allocating lots of memory that you don't later release. On iOS in particular, it's important to make sure that you give up allocated memory when you no longer need it, or your app's memory usage will grow until the OS terminates your app.
That really depends on how well you tested it with leaks but keep in mind that as hard as Leaks tries its not bulletproof, though if you do a through job you can be reasonably sure about your app. Don't forget to also use instruments other than leaks, the allocations tool is useful in picking up on abandoned memory which just Leaks won't point out to you but can be just as troublesome.
Your app does not run when you analyze, instead the static analyzer looks at your code. Regarding the instruments, check that your profile configuration (in edit scheme) is set to debug. Otherwise your app will be stripped out of symbols and the leaks instrument won't work.
you can assume it is in the best state now in which it could be.
My application is experiencing cashes in production.
The crash dump indicates a SIGSEGV has occurred in GCTaskThread
It uses JNI, so there might be some source for memory corruption, although I can't be sure.
How can I debug this problem - I though of doing -XX:OnError... but i am not sure what will help me debug this.
Also, can some of you give a concrete example on how JNI code can crash GC with SIGSEGV
EDIT:
OS:SUSE Linux Enterprise Server 10 (x86_64)
vm_info: Java HotSpot(TM) 64-Bit Server VM (11.0-b15) for linux-amd64 JRE (1.6.0_10-b33), built on Sep 26 2008 01:10:29 by "java_re" with gcc 3.2.2 (SuSE Linux)
EDIT:
The issue stop occurring after we disable the hyper threading, any thoughts?
Errors in JNI code can occur in several ways:
The program crashes during execution of a native method (most common).
The program crashes some time after returning from the native method, often during GC (not so common).
Bad JNI code causes deadlocks shortly after returning from a native method (occasional).
If you think that you have a problem with the interaction between user-written native code and the JVM (that is, a JNI problem), you can run diagnostics that help you check the JNI transitions. to invoke these diagnostics; specify the -Xcheck:jni option when you start up the JVM.
The -Xcheck:jni option activates a set of wrapper functions around the JNI functions. The wrapper functions perform checks on the incoming parameters. These checks include:
Whether the call and the call that initialized JNI are on the same thread.
Whether the object parameters are valid objects.
Whether local or global references refer to valid objects.
Whether the type of a field matches the Get<Type>Field or Set<Type>Field call.
Whether static and nonstatic field IDs are valid.
Whether strings are valid and non-null.
Whether array elements are non-null.
The types on array elements.
Pls read the following links
http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.50/html/jni_debug.html
http://www.oracle.com/technetwork/java/javase/clopts-139448.html#gbmtq
Use valgrind. This sounds like a memory corruption. The output will be verbose but try to isolate the report to the JNI library if its possible.
Since the faulty thread seems to be GCTaskThread, did you try enabling verbose:gc and analyzing the output (preferably using a graphical tool like samurai, etc.)? Are you able to isolate a specific lib after examining the hs_err file?
Also, can you please provide more information on what causes the issue and if it is easily reproducible?
I'm having a severe memory leak issue with my program. I'm using Apple's Instruments to track my leaks, and in the first few seconds after my app starts there are hundreds and hundreds of leaks listed. The problem is none of them seem to tell me where the leak is coming from.
I've gone through all my classes and made sure that anything that was alloced was released at the end, and garbage collection is enabled as well. Another big problem is I tried starting up my app without garbage collection enabled and it just crashes.
Any advice?
Thanks
EDIT: If the source code is needed then I can email it
Your question is tagged with "garbage collection".
Do you have GC turned on? If so, is it a command line tool? Did you call objc_startCollectorThread() as the first item in your main()?
If you have GC turned on, leaks analysis on Leopard will show quite a few false positives in certain circumstances. If you have access to Snow Leopard, I suggest you do the analysis there as the tools are significantly improved.
The clang static analyzer & Instruments are entirely orthogonal. You need to use both because the static analyzer isn't going to find all of the potential leaks in your code. In particular, it won't find situations where -- say -- you have unbounded cache growth or a global mutable set that is rooting your object graphs inadvertently.
Once you have fixed all of the problems the static analyzer finds, then use Instruments.
Try running your project through AnalysisTool and see what it finds. It's essentially a GUI front-end for the Clang Static Analyzer. It will run through your code and find errors such as leaks and bad releases, among many other things. It will then present them to you in a step-by-step manner to help you better understand where you made mistakes.
It's a fantastic tool.