Wondering if others have experienced this as well in Xcode: my app seems to have no crash issues when running normally OR in Instruments (Allocations) but if I run it from the debugger on my phone it will eventually (after ~10 rounds in my game) crash due to memory error (no other information provided).
One thought: I have malloc stack logging enabled and was curious if this might lead to memory accumulation that is unrealistic otherwise. At this point it seems like there's no real-world / non-debugger issue based on my testing, but as a relative rookie at memory management I am uncomfortable saying Xcode is giving me a false positive. Any ideas?
Related
I am new to Xcode and the profiling tool, instruments. I tried to find leaks of my c program. Everything is fine. It shows no leaks, but I don’t understand some terms used in the program. Does mean I still have memory leaks somewhere else in the program?
Applications like the debugger and Instruments may hook into your program after the OS has already started it running. What the message is saying is that it doesn't know how a given piece of memory was allocated because it was allocated before Instruments hooked into your program. So it has no way to track where it came from. It may or may not mean that there are more actual leaks in your program.
I believe that you can start your program from Instruments in most cases, which I think would eliminate the issue. Once you've run it once, you should be able to press the Record button (the red circle) again and it should run the app once more. I think in that situation, it should have access to all of the allocations your app makes.
For what it's worth, I have seen this message before and had it go away during the same run. It was as if it suddenly found the data that explained where the leak came from. I've also seen it happen on one run and be gone on a subsequent run with the same data. In that case it seemed like a timing issue of Instruments and not a legitimate leak.
Encountering a crash for a iOS9 only. The crash is manifesting in JavaScriptCore though I'm not certain it has anything to do with JavaScriptCore. I'm more inclined to believe this is an issue with memory exhaustion more specifically and possible virtual memory exhaustion. As noted in the screenshot free RAM is exceptionally low so it's definitely not an ideal situation. I don't know enough about iOS internals to entirely what's going on here but wondering if there's others out there who have encountered this type of thing with iOS9. This was not an issue for me on iOS 7.x, iOS 8.x
The issue in this case appears to have been from releasing a JSContext object from a section of code which was not the owner that was setup to run JavaScript. Xcode flagged it in the static analyzer and once the release call was removed all was well. I'm a bit hesitant to say this was for sure the issue since the crash didn't happen 100% of the time but given the testing before/after the change it seems pretty likely.
I'm currently writing an OpenGL renderer on my 2011 13" MacBook Pro with a Sandybridge graphics chip.
I'm finding that I'm encountering a lot of kernel panics and reboots when developing OpenGL code. Frequently, whenever I have an error, my system just reboots, rather than gives me chance to catch the error and retrieve an error code.
I know that it is related to the graphics driver as the resultant problem reporting app displayed at reboot identifies it as the entity that crashed.
The specific issue seems closely related to texture creation. Clearly there is some bug in my code, but regardless, this really shouldn't be rebooting the OS under a high-level API like OpenGL.
Does OS X have any kind of debug mode functionality that I might enable, similar to that of D3D, so that I can catch the error earlier, rather than have to use russian roulette debugging?
(I'm aware of the OpenGL profiler, Driver Monitor and so on, yet have had little success with using these tools to catch these sorts of problems)
As you mention, OpenGL Profiler is the tool to use. You should check the box marked, "Break on VAR error" and "break on thread error," at least. If you have trouble with it, let me know and I might be able to help. (I'm no expert but have had some luck with it.)
Beyond that, the crashes you're seeing are probably related to you giving a pointer to OpenGL, and it attempting to read or write memory from that pointer, but the pointer is bad (or the length of the data is wrong). If it's texture related, then perhaps you're attempting to upload or download a texture and passing the wrong width and height, or have the wrong format. I've seen this happen when passing an incorrect number of elements to glDrawElements(). I was confused about whether an "element" was a vertex or an actual object (like a QUAD or TRIANGLE) when it happened to me. The VAR error reporting helped me find that issue.
Just to come back to this for anyone looking... it turns out, that the problem was entirely related to failing to set the current context as different threads begun issuing OpenGL commands.
So, each thread needed to lock a mutex, set the open gl context, and then begin its work. It would then release the context and then the lock, guaranteeing non-simultaneous access to the one OpenGL context.
So, no deeply unknown behaviour here really, just an inexperienced newbie not fully implementing the guidelines out there. :-)
Others have responded with potential workarounds. But note that your application should never be able to cause the machine to panic (which these days simply reboots the machine and presents a dialog to submit the report to Apple).
At a minimum, you should send the report to Apple. Additionally, you should file a bug report at http://bugreport.apple.com including the panic log, a system profiler report, and any details you can provide about how to reproduce (ideally, a sample app binary and/or source code). Filing your own bug report will help in many ways -- prioritizing your bug (dupes bump priority), providing reproduction steps in case the problem & fix aren't obvious from the backtrace in the panic report, and opening a channel between you and Apple in case they need more information from you to track it down.
I am looking for ways in which memory leaks could be detected at the time of development something like a dump of leaks on console.
I am not talking about using leaks, shark, instruments. We use them after development. Sometimes finding the leaks after all development is real pain.
Thank you
When you build your app, you should always also perform "Analyze". It's available just below the build command in the menu if you use Xcode 4. This will catch almost all Objective-C leaks, and shows how an object is leaked as a curvy lines connecting the program texts.
Eliminate all warnings by the analyzer. That will solve 90% of the leak before even running your app.
I'd like to realease a Java application in debug mode to allow for easier debugging when random or hard to reproduce problems occur on the customer side.
However, I want to get a heads up on potential side effects of doing this? From the Java HotSpot Documentation it seems that there should be no performance penalty.
From the link
Full Speed Debugging
The Java HotSpot VM now uses
full-speed debugging. In previous
version of the VM, when debugging was
enabled, the program executed using
only the interpreter. Now, the full
performance advantage of HotSpot
technology is available to programs,
even with compiled code. The improved
performance allows long-running
programs to be more easily debugged.
It also allows testing to proceed at
full speed. Once there is an
exception, the debugger launches with
full visibility to code sources.
Is this accurate or are there hidden caveats, what about memory footprint and are there any other hidden gotchas while using debug mode.
PS: I found this article from AMD which confirmed my initial suspiciion that the original article from oricale doesn't show the full story.
I can't speak for HotSpot, and won't officially for IBM, but I will say there are certainly legal kinds of optimization that aren't possible to undo fully should a decompilation be required in the middle of them, and thus aren't enabled when debug is being asked for in the production JVMs you are likely to use.
Imagine a situation where the optimizer discovers a part of the program is provably not required and by the various language rules (including JSR 133) is legal to remove, the JVM will want to get rid of it. The one wrinkle is debug: removing the code will look odd to the human stepping through it (variables not updating, possibly not stopping on lines when stepping) so the choice is to disable said optimizations in those cases. The same might also be true for opts like stack allocated objects, etc.. so while the JVM says it's "full speed" it's actually closer to "nearly full speed, with some of the funkier opts that can't quite be undone removed".
This question is old but came up while I was searching for any performance impact if you just leave -agentlib:jdwp... on but are not actively debugging.
Summary: Starting with debugging options but not connecting shouldn't impact the speed now (Java 7+).
Before java 6 (ish) you used -Xdebug and this had a definite impact, it shut off the JIT!
In java 6 they changed it to -agentlib and made it better. there were some bugs though that did cause a performance penalty. Here is one of the bugs that was filed against openjdk, My guess is that there were similar problems with The oracle/sun version: https://bugs.openjdk.java.net/browse/JDK-6902182
Note however that the stated goal is that simply enabling debugging by opening the port should not cause any performance penalty.
It looks like, at least in openjdk, the bugs were cleaned up by java 7. I didn't see anything about performance impacts after that.
If you research this further and find negative results, take note of the java version the testing was done under--everything I saw was referring to versions before 7.
I'd love to hear if anyone encountered performance problems in a recent VM just leaving the port enabled.
If you plan to run the app with remote debugging enabled, it can affect security also. Remote debugging leaves a port open on your machine, and by connecting to it, I can do all sorts of fun things with your application.
The program definitely does lot more than simply running when in debugging mode, so it is obvious that performance can not be same. However if you read the statement carefully, it says that new release can run fully optimized code even if in debugging mode which was not possible earlier. Thus the new jvm is much more faster than previous one which could only run in interpreted mode which no optimization.