I'm currently migrating the Fragaria framework from a GC-only environment to GC being supported. After the work was done (or what I thought had to be done to make it work) I was able to run the examples that come with the framework without any problems and Instruments didn't show any major memory leaks.
I included non-GC Fragaria in my non-GC application and it crashes as soon as I place the cursor on it. To be honest the usage pattern is different from the examples as I'm embedding it in an instance of NSViewController instead of NSDocument.
Can you give me some tips on how to debug this? I'm a bit lost on where to proceed now.
First thing to do is Build and Analyze the code, then fix any problems it finds.
Next, try running with Zombie detection enabled (google NSZombie).
Finally, each crash's stacktrace should give you a pretty good idea where things have gone off the rails.
Related
I go through some tutorials of Java Profilers (JVisualVM, JProfiler, YourKit) on Youtube as well as Pluralsight. I got a little bit idea regarding how to check heap-dump and how to find the memory leak. But these all tutorials are elementary.
My query is, when I analyse in heap-dump, I saw only 3 types of objects char[], java.lang.String and java.lang.Object[] which covers almost all memory(more than 70% always). But none from my application.
And the same way for thread dump, I saw HTTP-8080 request (the port I am using) and that leads me to Runnable()'s run method or Java Concurrent Package and again not to any specific code to my project.
I also discussed the problem with some of my friends and analyse their application as well (which doesn't face any issues regarding memory leak and performance), but their results are almost the same.
Would you guys help to understand how to analyse heap-dump and thread-dump in JVisualVM for the large scale application? Any video, blog, anything would be helpful.
I am using OpenJDK-11, AWS ECS-Docker and Tomcat as a web-server.
Checkout the Eclipse Memory Analyzer (https://www.eclipse.org/mat/), I used it in the past several times to successfully find memory leaks, but it takes some time to get familiar with it.
Another advise I can give you is to create benchmark tests with Apache JMeter (https://jmeter.apache.org/) or another tool that lets you reproduce the performance/memory issue and identify the execution path that cause you problems.
Be aware AWS doesn't like when someone execute performance/penetration tests against their services (https://aws.amazon.com/aup/)
I recently have been getting memory warning messages when I load my app on my iPhone. I believe it has something to do with the storyboard that I recently switched over to from the classic .xib files. The app has been running a lot slower since and I don't get why. I got rid of a ton of my code that I was using for loading views, making tables, etc., so I would think that my app would run a lot faster now than it did before. My mainViewController (which is giving me the most problems), only has the default code in it! Is there a reason for this to be happening? Was the code running faster than storyboard or something?
Thanks in advanced.
Profile using Instruments to understand your app's execution -- CPU time (slow) and Allocations (memory consumption).
I am getting close to finishing the release of my application and are trying to use Instruments to fix any memory leaks.
How come that I can spot one memory leak when using Instruments and my device but not when I am using the iPhone simulator? I understand that this is a high-level question, but I don't think posting any code would help anyways (quite a bit of code...).
And is it possible to get instruments to point to the source code where it think the leak is? I can do it when using the simulator, but it seems like it doesn't work when using it for the device (objects are represented by the address (I assume) while running it for the simulator it sees what object it is, setup issues?)
Thanks in advance!
Regards,
Niklas
Update: Could it have something to do with that OSX is having automatic garbage collection but iOS doesn't?
Trust only the device. That's what your user will use to run your application.
Don't trust the simulator.
As a demonstration of this, I just intentionally added a leak to a project. The leak was not detected while in the simulator, but showed up as expected on the device.
The simulator is just that: a simulator. It can be useful to work faster, but is never a replacement of the device.
Once Instruments showed you a leaked object, you can double click on it. It will show the part of your code responsible for the leak. This works for the simulator and the device.
When you compile for the device, make sure you are in debug mode (and that the settings for this mode kept all your symbols).
Some more tip that you might find useful:
For a more fluid session, disable the "Automatic Leaks Checking", and manually press the "Check for Leaks Now" button when appropriate.
The "Build and Analyse" command will do a fantastic job to help you find leaks. It's not (totally) magical, so it won't find all leaks. For example, iVars leaked won't be identified. But for the scope of a method, it's just awesome.
I highly recommend to activate the "Run Static Analyser" flag in your build settings (or only for the Release mode if you have a slow to compile machine).
If you want more info about how to use Instruments to find leaks, read this Apple doc: Instruments User Guide: Built-in Instruments and Instruments User Guide: Viewing and Analysing Trace Data > Looking for Memory Leaks
You can also watch the video of the WWDC related sessions.
If you still don't understand where your leak come from, it's time to (re)read the Memory Management Programming Guide.
Thank you for wanting to ship a leak-free application. With iOS 4, it's now more important than ever.
If you haven't already take a look at the handy "Build and Analyze" option in the build menu. It will run the static analyzer which generally does a great job. If nothing turns up with that you should could some time reviewing the WWDC session videos on Instruments.
There is no substitute for profiling on hardware and with the debugger and instruments connected you can get everything you would in a simulator context.
I am getting Out of Memory errors in classic ASP, probably where attempting to access data. For example:
Microsoft VBScript compilation error '800a03e9'
Out of memory
(some file) Line 0
These errors only happen once in a while and they keep happening for a few minutes and then the webserver must be restarting the app pool because all sessions are lost.
What is a good tool for finding/diagnosing memory leaks in a classic ASP application that makes heavy use of ADO for data access and a couple of other off the shelf COM objects.
Presumably any memory leaks would be from the COM object rather than the script, so a general Windows debugger or leak finder might be what I need. Any advice on what would be appropriate?
Or any other thoughts on what might cause these errors?
Unfortunately, tracking down memory leaks is not an easy task :-(
Here's a good summary of things to watch out for here:
http://www.leinadium.com/code/classic-asp-memory-leaks-in-iis/
Be sure to read the link inside that post as well for a list of tools.
Good luck!
Microsoft has a good utility umdh.exe that may be good for finding leaks in this situation. It allows you to take a "snapshot" at one point, exercise the application (e.g., IIS) then take another snapshot and compare the memory usage differences.
if
you try to get one row data with EOF OR BOF
or
the database connection is close or readony you try to wirte!
you should get the ERROR.
I've used the CF Remote Performance Monitor, however this seems to only track memory initialised in the managed world as opposed to the unmanaged world. Well, I can only presume this as the numbers listed in the profiler are way short of the maximum allowed (32mb on CE 5). Profiling a particular app with the RPM showed me that the total usage of all the caches only manages to get to about 12mb and then slowly shrinks as (I assume) something unmanaged starts to claim more memory.
The memory slider in System also shows that the device is very short on memory. If I kill the process the slider shows all the memory coming back. So it must (?) be this managed process that is swallowing the memory.
Is there any simple(ish?) fashion how one can track unmanaged memory usage in some way that might enable me to match it up with the corresponding P/Invoke calls?
EDIT: To all you re-taggers it isn't .NET, tagging the question like this confuses things. It's .NETCF / Compact Framework. I know they appear to be similar but they're different because .NET rocks whereas CF is basically just a wrapper around NotImplementedException.
Try enabling Interop logging.
Also, if you have access to the code of the native dll you are using, check this out: http://msdn.microsoft.com/en-us/netframework/bb630228.aspx
I've definitely been fighting with unmanaged issues in a C# managed app for a while -- it's not easy.
What I've found to be most helpful is to have a regular output to a text log file. For example you can print the output of GlobalMemoryStatus every couple of minutes along with logging every time you load a new form. From there you can at least see that either memory gradually erodes, or a huge chunks of memory disappeared at specific times of the day.
For us, we found a gradual memory loss all day as long as the device was being used. From there we eventually found that the barcode scanning device was being initialized for no particular reason in our Form base class (I blame the previous developer! :-)
Setting up this logging may be a small hassle, but for us it paid huge dividends in the long run especially with the device in live use we can get real data, instrumentation, stack traces from exceptions, etc.
Ok, I'm using C++ on CE, not C# so this may not be helpful, but...
I use a package called Entrk toolbox which monitors memory and resource usage, leaks, and exceptions under Windows CE. Pretty much like a lightweight CE version of boundschecker. Does the trick most times.