views:

370

answers:

7

hello all,

i have a aplication on the android market , in wich exceptions and errors are catched and sent to me by acra.

But i receive quite a lot out of memory errors.. In different kind of classes...some my app, some general java..

Does this always mean there is a problem in my app, or can it also be the phone ran out of memory due to a other process?

Will users also get a fc dialog ?

thnks

Additional Information

There is nothing memory intensite in my app..

no images...no big chunks of data.. only a simple view..and most intensive a mobclix ad..

i'm new to java...so i may have a leak somewhere..but i do find it hard to debug that. But at this point i'm not even sure there is someting wrong...

i get about 25 -50 OOM error's daily..but compared to 60.000 ads it shows a day. (i show only 1 or 2 ads for each time it's started) that is not too much.

1 receive errors like :

"java.lang.OutOfMemoryError
at org.apache.http.impl.io.AbstractSessionInputBuffer.init(AbstractSessionInputBuffer.java:79)
at org.apache.http.impl.io.SocketInputBuffer.<init>(SocketInputBuffer.java:93)
at android.net.http.AndroidHttpClientConnection.bind(AndroidHttpClientConnection.java:114)
at android.net.http.HttpConnection.openConnection(HttpConnection.java:61)
at android.net.http.Connection.openHttpConnection(Connection.java:378)
at android.net.http.Connection.processRequests(Connection.java:237)
at android.net.http.ConnectionThread.run(ConnectionThread.java:125)

"

"java.lang.OutOfMemoryError
at java.io.BufferedReader.<init>(BufferedReader.java:102)
at com.mobclix.android.sdk.Mobclix$FetchResponseThread.run(Mobclix.java:1422)
at com.mobclix.android.sdk.MobclixAdView$FetchAdResponseThread.run(MobclixAdView.java:390)
at java.util.Timer$TimerImpl.run(Timer.java:290)

"

"java.lang.OutOfMemoryError
at org.apache.http.util.ByteArrayBuffer.<init>(ByteArrayBuffer.java:53)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.init(AbstractSessionOutputBuffer.java:77)
at org.apache.http.impl.io.SocketOutputBuffer.<init>(SocketOutputBuffer.java:76)
at android.net.http.AndroidHttpClientConnection.bind(AndroidHttpClientConnection.java:115)
at android.net.http.HttpConnection.openConnection(HttpConnection.java:61)
at android.net.http.Connection.openHttpConnection(Connection.java:378)
at android.net.http.Connection.processRequests(Connection.java:237)
at android.net.http.ConnectionThread.run(ConnectionThread.java:125)

"

So the main question is..am i leaking somewhere.. or can this be considered normal because in a small % of cases the phone may be out of memory due to other aplications running on it.

Thanks..

A: 

There are things that may be out of your control (memory on the phone is an example) but nonetheless you're responsible for the behavior of your application.

How you handle memory issues will influence how users view your application. If it plays well with other applications, users will be more likely to use it. If it doesn't, they won't.

John at CashCommons
A: 

What do you mean by "general java" exceptions and if these are unrelated to your piece of software, then why are you receiving them?

As you probably know, the Dalvik virtual machine only has a small amount of memory allotted to itself (and to your application). This is implemented this way to avoid the possibility of a process growing out of control and draining all of the available resources, making the phone unusable. So if your application is performing many memory-intensive operations (like loading pictures) and you are not careful with your allocations (and clearing them as soon as they are unneeded), then bizarre outcomes may be observed.

About the force close, since you are catching these exceptions, they should not cause a crash of your application, unless you have missed to re-instantiate something after you have caught an exception.

Maybe inspection of your code and elimination of unneeded memory allocations will prove helpful. Also, you can test as my boss does - he just freaks out pushing buttons at random until something crashes :D

EDIT

Since you say that there is nothing memory expensive in your code (sans the ads probably), then you can have a simple check to see if the whole system is being low on memory when the error occurs, or it is your application that causes it. Have a look at the onLowMemory callback. It is called when the whole phone is low on memory.

Shade
A: 

Question Merged on top.

arnold
A: 

Have you used allocation tracker in DDMS? Could help you find unexpected memory leaks. http://developer.android.com/resources/articles/track-mem.html (I haven't used it myself so far though)

ThomasJ
A: 

As Thomas suggested, you really want to use the DDMS to look at your memory usage.

Also, a very common problem for leaks is use of static variables - use them only if you know what you're doing.

Handling bitmaps can also get very expensive on Android. What does your app do? Also, do you have lots references to any UI elements? Any ones defined as static?

EboMike
A: 

When you get OutOfMemoryError, you can be sure it is your application and not another one which causes it. Each Android app is run in it's own Dalvik VM with 16Mb of maximum memory allocation.

If you do not use bitmaps (which are a frequent source of memory leaks), you also have to check if you handle orientation changes correctly, that is without keeping in memory any reference to an object relative to the UI.

Kevin Gaudin
+1  A: 

A common JVM problem is that only unreferenced objects can be removed by the Garbage Collector. If you have large persistent objects then it's important to set unused variables in those objects to null so that they are dereferenced. A classic problem is keeping something like a HashMap object around with a lot of values in it when you don't need it since every entry in the HashMap is chewing up memory.

Michael Shopsin