I created a simple hello world app using eclipse for android.
I am seeing 8MB+ heap space used in ddms heap view when launching this application.
There are no assets added and its a simple textview.
Does this 8MB include some shared memory from framework like the framework resources?
I cannot account for 8MB otherwise ....
thanks
Related
I'm failing to find concrete information on troubleshooting Out of memory exceptions for RN apps running on Android. I've been getting some OOM errors reported to my Bugsnag dashboard, all of which seem fishy.
The crashes are occurring on the login screen, before any heavy logic / rendering / etc. occurs.
The reported memory usage is low (one crash occurred with 3MB used by the app). This may not include anything used in the NDK though after emailing Bugsnag.
Available memory is far beyond used memory (though not including what is used by the NDK)
This is not isolated to older devices - one crash occured on a Galaxy S9 with the app using 13MB (plus NDK), and 255MB still available.
I of course enabled largeHeap for the time being while I investigate, but I'm still seeing crashes with this low reported memory usage. The only direction I have is checking if RN is eating up native memory, which isn't reported as 'used memory' in my console.
While profiling my app (using a debug variant APK, not against the development server), I do see the native memory usage seems high - 81mb with the app just sitting for a while after logging in. It hovers around 30-40mb prior to logging in.
I've ensured my code isn't making any API calls or loading resources during the crash workflow. The login is fairly simple, consisting of a gradient, some text and views, and react-native-app-auth being loaded to handle a login. I do not see a spike when performing the authentication in that library.
Are there any tools or methods to check why RN is eating so much native space? Or is this just normal? I'm currently on RN 0.57.5, React 16.6.3. I cannot test on iOs devices to check if this is an Android-specific problem.
did you try this ?
Add this to your "android/app/src/main/AndroidManifest.xml"
<application android:largeHeap="true"
ref: https://github.com/facebook/react-native/issues/6799
Is it possible to read android mobile device RAM content.
I am able to see passwords in RAM using HxD editor.
Is it possible to view the password using any tool on device?
Just taking a heap dump of ram with android studio dude.
You take the heap dump and seek the package name you are looking for and probably you can find passwords and whatever is in RAM.
I downloaded Red gate ANTS Memory Profiler and profiled my app. I noticed that my app had a lot of unmanaged memory allocated (160MB). So I ran the profiler again with unmanaged memory profiling enabled. The break down of the unmanaged memory as follows:
WindowsCodecs: 45.19MB
CLR: 43.21MB
Allocated by Managed code: 30.23MB
Allocated before profiling started: 2.047MB
d3d9: 595.5KB
Other modules: 67.27MB
Other modules also contains the red gate memory profiler which accounted for 64.94MB of the 67.27MB.
From reading the Red Gate documentation, loading the CLR is expected to be around 40MB and my managed code allocating 30MB seems reasonable. But I am confused by the WindowsCodecs taking up 45MB! I am assuming that WindowsCodex is related to video codecs or playback. My app does not use Windows Media Player media control nor does it do any media playback of any sort (audio or video).
Anybody run into this? It appears my app could get a 45MB memory footprint reduction if I can figure out what is pulling in this dependency.
.Net winform application.
I used several memory profiler, including CLR profiler, DotTrace memory, Net memory profiler.
The tools gave the result that the allocated memory was 38-40M. But I found that working set was 300-400M in task manager(almost the same size as Peak working set or memory or commit size.
So what's the difference between the two results? What do the results mean?
those tools may show you private bytes or managed heap size, this does not include, e.g. memory mapped file, either page file backed or disk file backed, your app may be r/w ing
big mapped file, so working set looks big, or your app just load too many dll/assemblies.
VMMAP (from sysinternals) can give a clear overview of memory type/size in your app.
I've run into a few OutOfMemoryExceptions with my C#/WPF application and I'm running into some confusing data while attempting to profile the memory usage.
When the app is typically running, Windows Task Manager shows the memory usage as somewhere around 34 MB (bounces around slightly as objects are created and garbage collected). When I run memory profiling applications such as CLR Profiler and dotTrace Memory, they show the total memory usage at around 1.2 MB.
Why this huge discrepancy? What does Task Manager see that these profilers do not?
UPDATE: I added some diag code to my application to print out various memory information every so often via the Process class.
While running my app, I set up a rule in DebugDiag to perform a memory dump in the event of an exception. I forced an exception and the memory dump occurred. At this point, the memory usage of my app (as shown by task manager) jumped from 32 MB to 145 MB and remained there.
You can see this jump in the table below (WorkingSet64). I'm still trying to make sense of all the types of memory info provided by the Process class. How would an external application make the working set of my app grow like this?
Link to data table here.
Using some of the diagnostics tools suggested here, plus the ANTS memory profiler (which is so money) I found the source of the leak.
WPF Storyboard animations leak under .NET 3.5
The WPF BitmapEffect class can cause leaks. The alternative "Effect" class fixes the leak. Link, Link
XAML Merged ResourceDictionaries can cause leak. Link, Link
The "Working Set" memory footprint of an application (memory shown by task manager) is not a good indication of your process' footprint. Outside applications can influence this. Link
The memory profiling tools helped me find that the leaks were mostly in unmanaged code, which made it a real pain to track down. Dealing with these leaks, plus a better understanding of Windows memory (private vs working set) cleared things up.
Prcess Explorer and VMMap, both part of the Sysinternals Suite by Mark Russinovich.