Hi,
on a regular JVM you can generate a dump in the very moment the
first OOM occurs (starting it with the -XX:+HeapDumpOnOutOfMemoryError
option), which is very useful.
From your previous posts I have deduced that's impossible with
Dalvik... am I right? are you considering this feature?
On Feb 23, 4:28 am, qvark joseluishuertasfernan...@gmail.com wrote:
on a regular JVM you can generate a dump in the very moment the
first OOM occurs (starting it with the -XX:+HeapDumpOnOutOfMemoryError
option), which is very useful.
From your previous posts I have deduced that's impossible
Ah yes, perfect! Works like a charm now - I had not been aware of the
need to use su.
Thanks!
On Feb 5, 2:05 am, fadden fad...@android.com wrote:
The adb daemon still runs as a regular user on the ADP1. You need
to run su to become root, then issue the chmod.
Thank you again for this very informative post. However,
In the mean time, you need to use a development device or the
emulator, either of which will allow you to chmod777 /data/misc.
For me this works fine on the emulator, but it does not work
on my dev phone 1 (which I did not re-flash or
On Feb 4, 3:07 pm, blindfold seeingwithso...@gmail.com wrote:
C:\Android\android-sdk-windows-1.0_r2\toolsadb -d shell
$ chmod 777 /data/misc
chmod 777 /data/misc
Unable to chmod /data/misc: Operation not permitted
The adb daemon still runs as a regular user on the ADP1. You need
to run su
Thank you for the additional information. I will look into it later.
One thing that kept me from further working with this a few days ago
is that I ran the monkey tool with the --hprof option, which according
to http://code.google.com/intl/zh-TW/android/reference/monkey.html
puts results in the
On Feb 3, 1:42 am, blindfold seeingwithso...@gmail.com wrote:
One thing that kept me from further working with this a few days ago
is that I ran the monkey tool with the --hprof option, which according
tohttp://code.google.com/intl/zh-TW/android/reference/monkey.html
puts results in the
On Jan 31, 1:12 am, blindfold seeingwithso...@gmail.com wrote:
When compiling hprofConv.c I noticed that stdint.h is not included
with Visual Studio C++ products (http://en.wikipedia.org/wiki/
Stdint.h), so I fetched the portable stdint.h pstdint.h from the web
No I was not using a debugger, just DDMS.
2009/2/1 EboMike ebom...@gmail.com
Guillaume, that kind of sounds like you're running with a debugger
attached... see somewhere in the middle of this long thread, it is
known that the system will leak memory when you run with a debugger
attached -
Thank you very much, fadden! It is much appreciated. For now I appear
to have fixed not only my run-to-run memory leaks but also the
frequent multi-run crashes by ensuring that my threads finish. From
reading this group I had just been looking in the wrong direction when
hunting for context leaks
There is bug in BitmapFactory memory allocation, there are tons of
threads in this mailing list dealing with that.
To sum up:
At a normal time when you create an object, the heap size is
automatically grown if not sufficient enough (there is an absolute
limit of 16MB per process though, you will
Guillaume, that kind of sounds like you're running with a debugger
attached... see somewhere in the middle of this long thread, it is
known that the system will leak memory when you run with a debugger
attached - mostly when exceptions are involved, and
BitmapFactory.decodeFile() always throws
I read in this post that I am supposed to have 16Mb available for my
computer, but when I check the heap size it is never 2.8Mb, and
yet it still crashes.
Did you make any progress on this? Your description sounds very
similar to what I experience with my own app. My app never uses more
than
Never mind, I found the culprit and fixed it. Not killing all threads
when pressing the back button seems to have been the root cause of my
problems.
On Jan 30, 6:08 pm, blindfold seeingwithso...@gmail.com wrote:
I read in this post that I am supposed to have 16Mb available for my
computer,
On Jan 30, 3:39 pm, blindfold seeingwithso...@gmail.com wrote:
Never mind, I found the culprit and fixed it. Not killing all threads
when pressing the back button seems to have been the root cause of my
problems.
FYI, we do now have a tool that can convert Android hprof output
into a format
I don't think I am doing anything funky.
Basically I have a view composed of two pages, one which is visible
and one which is invisible at any given time. When the visible page is
clicked, the visible page becomes invisible and the invisible page is
made visible.
One page consists of a gallery.
I have noted the following discrepancies compared to the descriptions
here, using a similar, simple application which uses Gallery, and
BitmapFactory:
1) EboMike, How exactly do I run the application without a debugger
attached? I assume that closing Eclipse entirely, and launching a
new
Hey gym,
1) You don't have to go that far. No need to close or reset anything,
simply run the app from within the emulator (obviously, you need to
update it via adb install -r or something if you changed it). It will
show up in the process list in the DDMS, but you'll see that it
doesn't have
Thanks for your comments.
It is now clear that I was running without the debugger enabled in the
first place. Therefore my OOM may have been related to the
BitmapFactory.decodeFile(), instead of the gallery itself. So I tried
enabling the debugger, but I do not see the gallery alone generate an
On Jan 8, 8:06 am, EboMike ebom...@gmail.com wrote:
For a simple demonstration of how BitmapFactory leaks, try this:
In the debugger, add an exception break on caught/uncaught instances
of IOException, and you will see BitmapFactory.decodeStream() calling
BufferedInputStream.reset():
As mentioned in other threads I've also had consistent problems
with BitmapFactory.decodeFile() causing out of memory problems where
there should be lots of memory available. I'm quite sure there is some
kind of bug causing this problem, but I cannot get this officially
confirmed. Many other
Mark, did you try running without a debugger attached like I suggested
earlier in this (or some other) thread? That fixed the BitmapFactory
problems for me.
On Jan 9, 1:53 pm, Mark K mark.ka...@gmail.com wrote:
As mentioned in other threads I've also had consistent problems
with
I've tried it with no de-bugger, on the emulator, and on actual G1
hardware, I can't seem to get rid of the problem entirely. I only
process and use one bitmap at a time, bitmaps are recycled after use,
and I invoke gc(). The Runtime free memory indicates that I always
have over 10 MB free,
On Jan 9, 4:47 pm, Mark K mark.ka...@gmail.com wrote:
I've tried it with no de-bugger, on the emulator, and on actual G1
hardware, I can't seem to get rid of the problem entirely. I only
process and use one bitmap at a time, bitmaps are recycled after use,
and I invoke gc(). The Runtime
For a simple demonstration of how BitmapFactory leaks, try this:
{
new Timer().schedule(timerTask, 10, 10);
}
TimerTask timerTask = new TimerTask() {
String filePath = [point this to a valid JPG file];
public void run() {
System.gc();
BitmapFactory.decodeFile(filePath);
On Jan 5, 1:59 pm, EboMike ebom...@gmail.com wrote:
This problem seems to be particularly prevalent with exceptions - I
wrote a test app that throws an exception every 10ms and it OOMs very
quickly (and you can see the memory pile up), but also with files
(which was what 6418 was about in the
On Jan 3, 12:18 am, EboMike ebom...@gmail.com wrote:
I take that back... I looked a lot more into the issue, and it seems
that the leak only occurs when a debugger is attached.
The interaction between GCs and debuggers is a little weird on a good
day. The current implementation of Dalvik
Thanks! (Romain just posted the same thing on the now-closed 6418
change).
This problem seems to be particularly prevalent with exceptions - I
wrote a test app that throws an exception every 10ms and it OOMs very
quickly (and you can see the memory pile up), but also with files
(which was what
I take that back... I looked a lot more into the issue, and it seems
that the leak only occurs when a debugger is attached.
Here is something to try when you're plagued by OOMs -- run your app
directly through the emulator without a debugger attached. Is the
memory situation any better?
I
We have also been noticing this kind of behaviour in our application.
What is worse, many of the OOM problems (but not all) have been solved
using explicits System.gc() calls before the operation that caused the
OOM. IMHO this means we were doing our homework releasing all the
references to
There is clearly something wrong. I've tried to plug a leak in
BitmapFactory.decodeStream() (which is called internally by
BitmapFactory.decodeFile() ), and that indeed fixed a memory leak
whenever you create a bitmap (see http://review.source.android.com/6418),
but after Romain reviewed it, I
I wonder if there could be some bug in this intended VM-like
behaviour, because my app continuously uses about 3 to 4 MB on the dev
phone 1 according to DDMS (with similar figures reported by freeMemory
()), and DDMS reports a heap size of about 6 MB (not a typo, not 16
MB). And yet my app
The heap works pretty much like in a regular VM. As your app needs
more memory the heap grows accordingly (but doesn't shrink.) For
instance, if you are using 1 MB out of your 2 MB of allocated heap and
need to load 2 more MB, the heap will grow to more than 3 MB, and you
will use 3 MB out of the
Hello Romain, thanks for your answer. The image I'm using is 1024x768.
I've tried a bunch of different ones, but they were all around that
size.
The 32KB leaks sound like the BitmapFactory's input stream buffers.
It should be possible to repro this behavior by creating a new Android
app in
I just checked and the bug is simply that Gallery does not convert the
views. I'll try to fix it as soon as possible.
On Wed, Dec 3, 2008 at 10:45 PM, EboMike [EMAIL PROTECTED] wrote:
I've already asked this in a href=http://groups.google.com/group/
Thanks a lot, Romain! Question though - even if the gallery is not
converting the views, why doesn't it release references to them as you
move away?
Say, I move from view 0 to view 1, with view 0 being completely off-
screen, the gallery should remove its reference to view 0 since it is
no
A memory leak is actually totally expected in that case. Gallery, like
ListView, GridView, etc. uses a recycling heap. Every time a view is
unused, it is moved to the recycler. Unfortunately, if it's never
taken out of the recycler...
On Wed, Dec 3, 2008 at 11:07 PM, EboMike [EMAIL PROTECTED]
Thanks a lot for the very quick replies. One last thing: Do you happen
to have any remote idea about when the next SDK release is scheduled?
My app is currently running out of memory a lot :)
On Dec 3, 11:13 pm, Romain Guy [EMAIL PROTECTED] wrote:
A memory leak is actually totally expected in
Well you could start by not loading such huge images in a Gallery.
Even if the recycler was working correctly it is a LOT of data to read
and to decode. It's also a lot of wasted memory (and it also slows
drawing down since the bitmaps are drawn rescaled.) You should use
BitmapFactory.Options or
Thanks, Romain. I'm grabbing them from a server, but you're right, if
anything, I should convert and re-save them in a smaller format before
caching them locally. Well, I just tried to get it running quickly :)
One laaast thing - You mentioned that an app has a 16MB heap. How is
that split up? A
40 matches
Mail list logo
