When chasing a problem like this a couple of years ago, my testing seemed to
indicate that setting a bitmap to null right after a call to recycle() was
leaky. It was as though the recycle call needed some time to work, and setting
null got in the way. I found it was better to just call recycle
Working with bitmaps is a little hard on Android.
One thing to do is to resize or pack them so that they take up less memory.
Another thing you may want to look into is to reuse the bitmap
object/memory. You may have to do this in native though.
As other have pointed out System.gc() just gives
Sorry for the large code. Thanks for your help. What I would like to
know is when to use weak references and if it is a good option while
using Bitmaps? If so how does it help?
/** This is the onPause function which releases the bitmap when the
imagebutton is clicked and gallery is displayed.
I realised that when when I made a call to System.gc() right after the
bitmao..recycle() call the heap space is getting returned to the VM
heap. But I have been reading about Garbage collection and it seems
that calling System.gc() is not a good programming practice. Is there
another way to make
You should work on getting a smaller example to demonstrate as this is too
much code to read through.
It may also help you solve the problem yourself.
On Dec 20, 2011 3:21 PM, shyama shyama.asoka...@gmail.com wrote:
I realised that when when I made a call to System.gc() right after the
A call to System.gc() doesn't actually start the GC process. All it does is
add the request to the queue. The operating system will then decide at its
leisure when to actually do the GC. So even calling System.gc() repeatedly
(as is sometimes recommended) is just another word for desperation.
No one having the problem? No one using mapview has leaks?
Or no know solution?
I'm very surprised as frustrated about that, because after some hours I
really don't know how to find a workaround and I don't know what more to
try...
I don't know how using a MapView without problems can be so
A situation requiring the urgent but careful implementation of the RMI
and XPR instructions
http://www.physics.ohio-state.edu/~bcd/humor/instruction.set.html
On Apr 7, 9:14 pm, TreKing treking...@gmail.com wrote:
On Thu, Apr 7, 2011 at 5:16 AM, NURAIZ yousuf_...@yahoo.com wrote:
Why our
Hi John (⌒o⌒)/, I resolve the problem.
this is link is the result:
http://groups.google.com/group/android-group-japan/browse_thread/thread/fa40fe4d250541f5/b75d9d97a479084f#b75d9d97a479084f
sorry this is japanes, but The Penultimate Post source is result.
have fun.＼(⌒∇⌒
--
You received this
hi John (⌒o⌒)/, this is link is possible solution, but this is
Japanese, sorry.
http://groups.google.com/group/android-group-japan/browse_thread/thread/fa40fe4d250541f5/f868bce5962fc34d#f868bce5962fc34d
the end topic is solution.
have fun. (^-^)/
--
You received this message because you are
Hi,
The dominator tree shows the largest objects in the heap. It shows
only the largest objects that are not retained by one single object.
It's therefore possible that your objects show not up there. Note that
currently the information shown by the Memory Analyzer does *not* take
the size of
On Mon, Oct 18, 2010 at 6:21 PM, DanH danhi...@ieee.org wrote:
I doubt that adding content to the object would make it any more
likely to be collected. The garbage collector doesn't generally
weigh objects as to whether they should be collected or not. The
only differentiating factors are 1)
On Tue, Oct 19, 2010 at 1:25 AM, Tom Gibara tomgib...@gmail.com wrote:
It is possible that the finalize() has been called at much later point.
I should have probably said that lack of finalize() does not mean that
the memory has not been regained.
This isn't correct. If an object is an
What if the system decides to send KILL to a process running
some background task (application) to regain memory.
In that case, the object's memory has not been reclaimed from the heap, the
heap has been destroyed. These are two different things: if the VM's process
is terminated, it's no
John,
You could try forcing GC (for debugging) by creating a thread that
allocates memory in a loop, something like this:
for (;;) {
byte[] buf = new byte[100 * 1024];
Log.i(TAG, new buf: + buf);
Thread.Sleep(100);
}
Note that references to these byte buffers are not kept around, but the
Yes, size matters from the standpoint of triggering GC, simply because
GC is generally triggered when the total amount of allocated space
exceeds some threshold (or when the amount allocated since the last GC
exceeds some threshold).
I worked on a GC implementation off and on for 12 years, so I'm
On Tue, Oct 19, 2010 at 11:57 AM, Tom Gibara tomgib...@gmail.com wrote:
What if the system decides to send KILL to a process running
some background task (application) to regain memory.
In that case, the object's memory has not been reclaimed from the heap, the
heap has been destroyed. These
finalize isn't guaranteed to be called. If you want to know if an
object has been GCed, create a WeakReference to it and test that after
the GC.
But note that full GC isn't guaranteed to occur when you do gc
either. And some systems require two GCs to trigger finalize (or
clear a
Thanks for the input. I am a little confused about your comment:
'The fact that you did not see the log from finalize() does not mean
it did not happen.'
Are you saying that the finalize can be called and yet I may not get
the log? How is that possible?
I added the call to super.finalize() as
On Mon, Oct 18, 2010 at 5:40 PM, John Gaby jg...@gabysoft.com wrote:
Thanks for the input. I am a little confused about your comment:
'The fact that you did not see the log from finalize() does not mean
it did not happen.'
It is possible that the finalize() has been called at much later
What I really want
is a way to find out whether an object has been freed (or will be
freed) or not. I believe that I must have objects that are not being
freed, and I would like to try and identify them.
You can use WeakReferences for that. Create a WeakReference for the
object. If the
On Mon, Oct 18, 2010 at 5:54 PM, Daniel Drozdzewski
daniel.drozdzew...@gmail.com wrote:
On Mon, Oct 18, 2010 at 5:40 PM, John Gaby jg...@gabysoft.com wrote:
Thanks for the input. I am a little confused about your comment:
'The fact that you did not see the log from finalize() does not mean
btw^2
Rather than assigning the same literal in the constructor, create new
String each time around the same literal:
/*
* My Class
*/
package com.gabysoft.memoryleak;
import android.util.Log;
public class MyClass extends Object
{
String balast;
MyClass()
{
balast = new
I doubt that adding content to the object would make it any more
likely to be collected. The garbage collector doesn't generally
weigh objects as to whether they should be collected or not. The
only differentiating factors are 1) the absolute size of the object
itself (not counting references to
18.10.2010 20:40, John Gaby пишет:
What I really want
is a way to find out whether an object has been freed (or will be
freed) or not. I believe that I must have objects that are not being
freed, and I would like to try and identify them.
This might be useful:
So there is no way to force all objects that no longer have references
to them to be garbage collected?
Once again, I really don't need to know when the object is actually
freed. What I am interested in is finding out whether it CAN be
freed. That is whether all the references to it are gone.
You probably do need one of the tools that dumps the heap and shows
you the classes of the objects found.
And do note that Android (outside of the pure Java issues) has
issues of its own with regard to image storage. You can obey all of
the Java rules on clearing references and still get bit by
It is funny that you mention images, because I am pretty sure that my
leak is associated with images not being freed.
Can you point me to a reference that discusses the heap dumping tools?
Thanks again
On Oct 18, 11:35 am, DanH danhi...@ieee.org wrote:
You probably do need one of the tools
Kostya's link was a good one.
On Oct 18, 2:17 pm, John Gaby jg...@gabysoft.com wrote:
It is funny that you mention images, because I am pretty sure that my
leak is associated with images not being freed.
Can you point me to a reference that discusses the heap dumping tools?
Thanks again
If I can make one more suggestion since you mention bitmaps
It might be useful to add explicit Java methods to clean up your objects
that hold references to bitmaps, and call Bitmap.recycle(). This method
immediately frees up the memory allocated to hold bitmap bits, leaving
only the
Thanks for the tip. I have installed the Eclipse Memory Analyzer Tool
and have been able to get a heap dump from my application to inspect,
but I am having trouble interpreting what I see. If I choose to look
at the 'dominator_tree. and sort by package it appears to show my
objects. I have a
Thanks for the tip. I have installed the Eclipse Memory Analyzer Tool
and have been able to get a heap dump from my application to inspect,
but I am having trouble interpreting what I see. If I choose to look
at the 'dominator_tree. and sort by package it appears to show my
objects. I have a
Thanks for the tip. I have installed the Eclipse Memory Analyzer Tool
and have been able to get a heap dump from my application to inspect,
but I am having trouble interpreting what I see. If I choose to look
at the 'dominator_tree. and sort by package it appears to show my
objects. I have a
Also, with respect to your suggestion that I call Bitmap.recycle(). I
am not sure how to do this since the images in questions are obtained
via a call to Resources.getDrawable() which returns a Drawable object
not a Bitmap.
Thanks.
P.S. Sorry about the multiple posts, I am not really sure how
On Oct 18, 8:58 am, John Gaby jg...@gabysoft.com wrote:
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
MyClass mc = new MyClass();
mc = null;
setContentView(R.layout.main);
System.gc();
}
An
It is possible that the finalize() has been called at much later point.
I should have probably said that lack of finalize() does not mean that
the memory has not been regained.
This isn't correct. If an object is an instance of a class with a
non-trivial finalize method, then the object's
hi John (⌒o⌒)/, I have the same problem. (～_～)
but still I could not fix it. (u_u,)
I call many times GC, and making recycle. but still get error.
if you found the solution could you please tell me. m(_ _)m
thank very much.
--
You received this message because you are subscribed to the Google
In that case, you could build a hub Activity that can start each of
your four Activities via startActivityForResult, then have the
Activities call setResult, passing back an identifier that the hub
Activity inspects in onActivityResult and uses to determine the next
Activity to start.
That way,
Looks like an easier way to do this might be to set android:nohistory
to true in the manifest. (http://developer.android.com/guide/topics/
manifest/activity-element.html#nohist)
On May 18, 9:10 am, blcooley blcoo...@gmail.com wrote:
In that case, you could build a hub Activity that can start
Thank you. This is very useful advise that I already verified in my
test app as working. Small problem is it seems the hub activity
flickers a bit when launching next activity from onActivityResult (it
does not flicker the first time when startActivityForResult is called
from the hub's onCreate).
nohistory does not work. The app runs out of memory.
On May 18, 12:33 pm, blcooley blcoo...@gmail.com wrote:
Looks like an easier way to do this might be to set android:nohistory
to true in the manifest. (http://developer.android.com/guide/topics/
manifest/activity-element.html#nohist)
On
On Tue, May 18, 2010 at 12:04 PM, ls02 agal...@audible.com wrote:
nohistory does not work. The app runs out of memory.
Have you looked at the singleTask flag?
-
TreKing - Chicago transit tracking
What about setting your activity's launchMode to 'singleTask' (or
'singleTop') and implementing onNewIntent()? This would cause your
current instance of your activity to be re-used.
On May 18, 1:04 pm, ls02 agal...@audible.com wrote:
nohistory does not work. The app runs out of memory.
On May
Yes, this is really what I need. Though I see that periodically my
singleTask activity contsractor and onCreate are called which means
that activity instance is probably periodically destroyed though the
activity's finalize is not called. But I tested my sample app and it
runs without running out
You could also be more proactive with releasing unneeded objects. Rather
than doing it in finalize (if that is how you do it), do object cleanup in
onPause.
18.05.2010 23:12 пользователь ls02 agal...@audible.com написал:
Yes, this is really what I need. Though I see that periodically my
I am not releasing objects in finalize. I just log all standard
methods to observe when they are called. My understanding that
singleTask activity is a singleton object that should not be destroyed
and one single instance should be reused. This does not happen.
Sometimes the activity's constructor
On May 17, 5:20 pm, ls02 agal...@audible.com wrote:
We found there are very nasty memory and resource leaks in activities
and views that we don't know how to handle. I have test app that
basically starts activity A, that immediately starts activity B and B
starts A and so forth in infinite
My understanding there is no way to start another activity reusing
existing activity instance. Both startActivity and
startActivityForResult create a new activity instance.
The sample app I describes shows very common scenario to my opinion.
An app can have several activities that can start one
There is nothing special in my sample app. It is bare born simple app
that consits of may be 50 lines of code and two classes. If you wish,
I can send you source code, you can see for yourself. Again, there is
no static or non-static members in any of the classes.
On May 17, 6:26 pm, Romain Guy
If you need information from B to be fed back to A, then start B by
calling startActivityForResult. Then, when B exits, call setResult,
and A will be on top of the Activity stack and its onActivityResult
will fire.
If you don't need information from B, then you can start B using
startActivity. A
The activity stack in my real app is not hard coded. A can start B, or
C which can start D and D can start A or B or C depending on user
selection or other flow. And this happens rather frequently. Each of
them in reality should exist in only one instance and the activity
should be shown or
Hi Aman,
The best way to analise memory leaks on Android is using Memory Analyser
Tool. (eclipse.org/mat)
Take some heap dumps using the command kill -10 pid, convert it to for
mat format using hprof-conv and then open the dump on MAT. And then have fun
:-D
Felipe Silveira
On Fri, Oct 23, 2009
Did you read that ?
http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html
On Feb 4, 12:46 pm, Gw1921 guidedw...@googlemail.com wrote:
Hi
I'm trying to track down memory leaks in my application. It seems the
total amount of memory the app really needs is perhaps around 3MB
Yes I did, thanks. There was indeed a problem with using static
variables to store reference to certain views which were being
overwritten/modified when the view was stopped/restarted/destroyed.
Thanks
On Feb 4, 10:18 pm, Alexey avolo...@gmail.com wrote:
Did you read that
54 matches
Mail list logo
