Application being closed ... Out of Memory?

[JYA]

Hi.

Puzzling behaviour of the VM in the emulator...

After returning from my JNI library:

After about 55-58 call to a function, returning a jstring using:
env->NewStringUTF

the application just closes...

I know for a fact (through the use of profilers and having used my
library in several other projects) that the heap stack usage is around
4kB...

The is what LogCat shows:

10-10 20:27:38.321: DEBUG/dalvikvm(753): Added shared lib /data/data/
com.hydrix.laurene/lib/libcalccore.so 0x43e379b0
10-10 20:27:38.321: INFO/CalcCore(753): JNI_OnLoad(): loading...
10-10 20:27:38.321: INFO/CalcCore(753): JNI_OnLoad(): finished...
10-10 20:27:39.691: INFO/ActivityManager(59): Displayed activity
com.hydrix.laurene/.Laurene: 2399 ms (total 2399 ms)
10-10 20:27:47.031: DEBUG/dalvikvm(753): GC_FOR_MALLOC freed 3370
objects / 213944 bytes in 93ms
10-10 20:28:03.601: INFO/ActivityManager(59): Process
android.process.acore (pid 301) has died.
10-10 20:28:04.941: DEBUG/skia(753): purging 191K from font cache [27
entries]
10-10 20:28:08.611: INFO/ActivityManager(59): Process
com.android.defcontainer (pid 324) has died.
10-10 20:28:10.811: INFO/ActivityManager(59): Process com.svox.pico
(pid 335) has died.
10-10 20:28:10.811: INFO/ActivityManager(59): Low Memory: No more
background processes.
10-10 20:28:11.482: DEBUG/skia(753): purging 192K from font cache [27
entries]
10-10 20:28:13.081: INFO/ActivityManager(59): Process
com.android.launcher (pid 294) has died.
10-10 20:28:13.081: INFO/ActivityManager(59): Low Memory: No more
background processes.
10-10 20:28:13.081: INFO/WindowManager(59): WIN DEATH: Window{43faca60
com.android.launcher/com.android.launcher2.Launcher paused=false}
10-10 20:28:17.542: DEBUG/skia(753): purging 198K from font cache [28
entries]
10-10 20:28:18.211: DEBUG/dalvikvm(123): GC_EXPLICIT freed 12730
objects / 566504 bytes in 109ms
10-10 20:28:23.121: DEBUG/skia(59): purging 79K from font cache [10
entries]
10-10 20:28:23.281: DEBUG/dalvikvm(59): GC_EXPLICIT freed 3028
objects / 250840 bytes in 159ms
10-10 20:28:26.652: DEBUG/skia(753): purging 192K from font cache [27
entries]
10-10 20:28:27.662: INFO/ActivityManager(59): Process
com.android.inputmethod.latin (pid 288) has died.
10-10 20:28:27.682: WARN/ActivityManager(59): Scheduling restart of
crashed service com.android.inputmethod.latin/.LatinIME in 5000ms
10-10 20:28:27.682: INFO/ActivityManager(59): Low Memory: No more
background processes.
10-10 20:28:31.171: INFO/WindowManager(59): WIN DEATH: Window{43f3da40
com.hydrix.laurene/com.hydrix.laurene.Laurene paused=false}
10-10 20:28:31.181: INFO/ActivityManager(59): Process
com.hydrix.laurene (pid 753) has died.
10-10 20:28:31.341: INFO/ActivityManager(59): Start proc
com.android.launcher for activity com.android.launcher/
com.android.launcher2.Launcher: pid=760 uid=10017 gids={}
10-10 20:28:31.341: INFO/ActivityManager(59): Low Memory: No more
background processes.
10-10 20:28:31.401: WARN/WindowManager(59): No window to dispatch
pointer action 0
10-10 20:28:31.511: WARN/WindowManager(59): No window to dispatch
pointer action 1
10-10 20:28:31.851: INFO/UsageStats(59): Unexpected resume of
com.android.launcher while already resumed in com.hydrix.laurene


Any suggestions?
and the string I'm allocating are tiny (7 characters) ...
It seems that the issue comes because the launcher also gets
killed ...

[Dianne Hackborn]

Is your process "com.hydrix.laurene"?  If so, yes, as the messages indicate it seems like you are consuming too much memory.  Obviously 4KB is not going to be too much memory, but *something* must be allocating a lot of memory to have the system yelling about running low.

Try using "adb shell procrank" to see how much memory processes are using as you are reaching this point.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[JYA]

Hi

On Oct 11, 1:09 am, Dianne Hackborn <hack...@android.com> wrote:
> Is your process "com.hydrix.laurene"?  If so, yes, as the messages indicate
> it seems like you are consuming too much memory.  Obviously 4KB is not going
> to be too much memory, but *something* must be allocating a lot of memory to
> have the system yelling about running low.

Yes it is com.hydrix.laurene.

I ran the library (I use the same library for a .Net project or
various iPhone ones) ; and profiler there showed that at the most 4kB
of heap memory is use at any given time. The library was designed for
embedded use, all variables used are static and pre-allocated before
the code even start.
The only difference with the JNI version is that env->NewStringUTF is
called on each of those strings..

I tried on a real device (HTC Desire) ; and while it takes many more
key presses to get the application to close it did happen. When it
did, I saw the HTC logo and the machine rebooted !

The key called only returns the static string "Conv", and I do
return env->NewStringUTF(str);

>
> Try using "adb shell procrank" to see how much memory processes are using as
> you are reaching this point.
>

Ok.. I'm going to test than..

In my experience those debugging steps always take an annoying amount
of time to find and more to fix :(

Thanks for your answer.
JY

[JYA]

Well.

Good news is that it's not the native library..

I replaced it with a java stub version ; and the process still grew
over 1MB each time I press a key.

I identified the culprit though;

I my drawing code; I was loading a font with:

Paint paint = new Paint();
Typeface font = Typeface.createFromAsset(getContext().getAssets(),
"fonts/Arial.ttf");
paint.setAntiAlias(true);
paint.setTypeface(font);

Arial.ttf is 770kB ; the memory used for it is never freed. I made the
font global ; loading it only once (which I should have done right at
the start), and now the application stays at a steady 7180kB.

I'm still puzzled why the memory used when loading the font each time
the display routing was called was never freed. That it was
inefficient I understand, but it shouldn't grow in memory no ?

Thanks
JY

[Dianne Hackborn]

It is probably because it is a native allocation, the Typeface object holds a reference to that, the Java VM doesn't know about it, so it doesn't think it needs to GC until well after too much memory has been allocated.

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[JYA]

Hi

On Oct 12, 6:17 am, Dianne Hackborn <hack...@android.com> wrote:
> It is probably because it is a native allocation, the Typeface object holds
> a reference to that, the Java VM doesn't know about it, so it doesn't think
> it needs to GC until well after too much memory has been allocated.

No.. This is entirely done in Java..

Even completely removing any native references, the problem occurs.

I allocated the Typeface object in the onDraw method.

memory is never freed in this case

[Tim Mensch]

On 10/11/2010 3:54 PM, JYA wrote:
> On Oct 12, 6:17 am, Dianne Hackborn<hack...@android.com> wrote:
> > It is probably because it is a native allocation, the Typeface object holds
> > a reference to that, the Java VM doesn't know about it, so it doesn't think
> > it needs to GC until well after too much memory has been allocated.
>
> No.. This is entirely done in Java..

A lot of Android is implemented in native; I'm sure Dianne means that
the allocation INSIDE the Typeface is done in native. So Java only knows
about (probably) a series of small allocations (that each internally
reference a larger native allocation), and therefore doesn't realize
that GC should be run ASAP.

Tim

[Zoran Angelov]

Hi,
Try calling jniEnv->DeleteLocalRef(retJstring);

VM does not automaticaly delete local reference of your new object.
Also after every GetStringChars, when yo don't need string buffer , call ReleaseStringChars.

On Oct 11, 2010 9:17 PM, "Dianne Hackborn" <hac...@android.com> wrote:

It is probably because it is a native allocation, the Typeface object holds a reference to that, the Java VM doesn't know about it, so it doesn't think it needs to GC until well after too much memory has been allocated.

On Sun, Oct 10, 2010 at 6:02 PM, JYA <jyav...@gmail.com> wrote:
>
> Well.
>

> Good news is that ...

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private ...

You received this message because you are subscribed to the Google Groups "android-ndk" group.

To po...

[Dianne Hackborn]

On Mon, Oct 11, 2010 at 3:25 PM, Tim Mensch <tim.m...@gmail.com> wrote:

A lot of Android is implemented in native; I'm sure Dianne means that the allocation INSIDE the Typeface is done in native. So Java only knows about (probably) a series of small allocations (that each internally reference a larger native allocation), and therefore doesn't realize that GC should be run ASAP.

Yep, that is what I meant.

[JYA]

Ah ok..

I understand now..

Kind of a worry though that I could so easily make my HTC desire
reboot simply by allocating memory for a font ..

[Dianne Hackborn]

On Mon, Oct 11, 2010 at 7:09 PM, JYA <jyav...@gmail.com> wrote:

Kind of a worry though that I could so easily make my HTC desire

reboot simply by allocating memory for a font ..

Talk with HTC about that.  You shouldn't be able to do that with the standard platform.  (Though at some point I would like to make things more aggressive about killing the foreground app when memory is extremely low.)