OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by Mark K » Tue, 16 Dec 2008 03:29:28 GMT


Sponsored Links
 've run into this exact same problem a number of times myself. Not
sure if its a bug or just a limitation of the jvm, can't seem to
process more than a few large bitmaps without this occuring, this
always seems to occur when decoding bitmaps from file. Hopefully its
on the radar as a bug and will get fixed at some point. This is a
problem since de-coding bitmaps from file is a fairly common
operation.

Mark

On Dec 14, 9:49am, plusminus <stoeps...@gmx.de> wrote:
--~--~---------~--~----~------------~-------~--~----~



OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by Mike Reed » Tue, 16 Dec 2008 05:15:45 GMT


 epending on the details, bitmap pixels may be allocated in the VM  
heap or in the native heap, but in the latter case, we still debit the
VM's heap by the amount that was allocated, so that in either case we
don't exceed the per-app budget. This may explain why you're running
out of heap even though DDMS doesn't see the allocations.


On Dec 15, 2008, at 2:29 PM, Mark K wrote:



I've run into this exact same problem a number of times myself. Not
sure if its a bug or just a limitation of the jvm, can't seem to
process more than a few large bitmaps without this occuring, this
always seems to occur when decoding bitmaps from file. Hopefully its
on the radar as a bug and will get fixed at some point. This is a
problem since de-coding bitmaps from file is a fairly common
operation.

Mark

On Dec 14, 9:49 am, plusminus <stoeps...@gmx.de> wrote:



--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by Mark K » Tue, 16 Dec 2008 10:04:25 GMT


 Is there a work around for this problem? Something I need to do
differently perhaps? It seems like garbage collection is not occurring
between successive bitmap decoding operations. Explicitly calling gc()
does not seem to help. This is particularly a problem on the G1,
because there is no way to reduce the camera resolution, all of the
camera pictures are large. If I loop through a directory of pictures
taken by the camera and use BitmapFactory.decodeFile(), I will get an
out of memory error on the 2nd or 3rd iteration. Since I am only
displaying/decoding one bitmap at a time I would hope that garbage
collection would free up the memory between operations such that this
does not occur. Any help would be greatly appreciated. Here's the code
I use: This code runs a slide show of the images in the camera
directory, it uses Handler.postDelayed() to render each picture. Is
there anyway to tweak the code to get rid of the out of memory
problem.

public boolean slideShow()
    {
        String baseDir = "/sdcard/dcim/Camera/";
        long showTime = 1500;

        File dir = new File(baseDir);
        File[] pics = dir.listFiles();
        for ( int i=0; i<pics.length; i++ )
        {
                String pic=baseDir+pics[i].getName();
                handler.postDelayed(new ShowSlide(pic), i*showTime);
        }
        return true;
    }

class ShowSlide extends Thread
    {
        String pc="";
        public ShowSlide(String pc)
        {
                this.pc=pc;
        }
        public void run()
        {
                System.out.println("Showing picture: "+pc.toString());
                displayPicture(pc);
        }
    }

public boolean displayPicture(String filepath)
    {
               File file = new File(filepath);
                BitmapFactory bfac = new BitmapFactory();
        try
        {
                bm = bfac.decodeFile(filepath);// out of memory error occurs
here!
                handler.post(new SetImage(iView, bm));
        }
        catch(Exception e)
        {
           Log.e(TAG,"display picture failed: "+filepath+" "+e.toString
());
           e.printStackTrace();
           return false;
        }

        return true;
    }

class SetImage extends Thread
    {
        ImageView vv;
        Bitmap bb;
        public SetImage(ImageView vv, Bitmap bb)
        {
                this.vv=vv;
                this.bb=bb;
        }
        public void run()
        {
                vv.setImageBitmap(bb);
        }
    }





--~--~---------~--~----~------------~-------~--~----~



OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by fadden » Wed, 17 Dec 2008 09:43:12 GMT


 On Dec 16, 10:34am, "aditya marella" <aditya.mare...@gmail.com>



What is the size of your image in pixels?

--~--~---------~--~----~------------~-------~--~----~



OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by Mike Reed » Wed, 17 Dec 2008 21:57:11 GMT


 ts a little raw, but if you know you're absolutely done using a given  
bitmap object, you can call bitmap.recycle(). This immediately frees
up the memory associated with the bitmap, and marks it as "dead",
meaning it cannot be referenced again (i.e. don't try to draw or get/
set its pixels anymore).

i.e.

for (all of my big images) {
Bitmap b = decode(...);
canvas.drawBitmap(b, ...);
b.recycle();
// yikes, don't reference b again)
}

On Dec 15, 2008, at 9:04 PM, Mark K wrote:



Is there a work around for this problem? Something I need to do
differently perhaps? It seems like garbage collection is not occurring
between successive bitmap decoding operations. Explicitly calling gc()
does not seem to help. This is particularly a problem on the G1,
because there is no way to reduce the camera resolution, all of the
camera pictures are large. If I loop through a directory of pictures
taken by the camera and use BitmapFactory.decodeFile(), I will get an
out of memory error on the 2nd or 3rd iteration. Since I am only
displaying/decoding one bitmap at a time I would hope that garbage
collection would free up the memory between operations such that this
does not occur. Any help would be greatly appreciated. Here's the code
I use: This code runs a slide show of the images in the camera
directory, it uses Handler.postDelayed() to render each picture. Is
there anyway to tweak the code to get rid of the out of memory
problem.

public boolean slideShow()
{
String baseDir = "/sdcard/dcim/Camera/";
long showTime = 1500;

File dir = new File(baseDir);
File[] pics = dir.listFiles();
for ( int i=0; i<pics.length; i++ )
{
String pic=baseDir+pics[i].getName();
handler.postDelayed(new ShowSlide(pic), i*showTime);
}
return true;
}

class ShowSlide extends Thread
{
String pc="";
public ShowSlide(String pc)
{
this.pc=pc;
}
public void run()
{
System.out.println("Showing picture: "+pc.toString());
displayPicture(pc);
}
}

public boolean displayPicture(String filepath)
{
File file = new File(filepath);
BitmapFactory bfac = new BitmapFactory();
try
{
bm = bfac.decodeFile(filepath);// out of memory error occurs
here!
handler.post(new SetImage(iView, bm));
}
catch(Exception e)
{
Log.e(TAG,"display picture failed: "+filepath+" "+e.toString
());
e.printStackTrace();
return false;
}

return true;
}

class SetImage extends Thread
{
ImageView vv;
Bitmap bb;
public SetImage(ImageView vv, Bitmap bb)
{
this.vv=vv;
this.bb=bb;
}
public void run()
{
vv.setImageBitmap(bb);
}
}



On Dec 15, 2:48 pm, Romain Guy <romain...@google.com> wrote:



--~--~---------~--~----~------------~-------~--~----~



OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by Mark K » Thu, 18 Dec 2008 03:21:08 GMT


 hanks for the beta on the bitmap,recycle(), it works! Before
processing the next bitmap I use this code to free up memory. I have a
class level Bitmap object.

Bitmap bm;// class level

if (bm!=null)
{
bm.recycle();
try
{
Thread.sleep(100);
}
catch(Exception e){}
bm=null;
System.gc();
try
{
Thread.sleep(100);
}
catch(Exception e){}
}
// create new bitmap and start again.


Thanks again, it works!


On Dec 17, 5:56am, Mike Reed <r...@google.com> wrote:
--~--~---------~--~----~------------~-------~--~----~



OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by Rohit » Fri, 09 Jan 2009 07:27:20 GMT


  am setting the Background (using view.setBackgroundResource()) of
about 5 views with pngs that fill up the entire screen (as a
backdrop). I scroll between these 5 views and thus want to keep them
in cache (I use view.setChildrenCacheEnabled()) but I run into the
OutOfMemoryError: bitmap exceeds VM budget error. Is there a way to
overcome it?

Rohit


n Dec 17 2008, 11:20am, Mark K <mark.ka...@gmail.com> wrote:
--~--~---------~--~----~------------~-------~--~----~



OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by Mark K » Fri, 09 Jan 2009 08:05:48 GMT


 'm still seeing this problem. I've used the bitmap.recycle() which
seems to mitigate this problem, but not get rid if it entirely. I'm
only processing one bitmap at a time, I recycle the bitmap, null it,
and call gc(). Runtime.freeMemory() indicates that I have over 10 MB
free memory, none of my bitmaps are over 3.5 MB, I only process one at
a time, yet this problem still occurs intermittently. Is this a bug or
low level memory leak? I've spent a considerable amount of time on
this issue, but cannot seem to resolve it. I'd at least like to know
if this is a documented bug, or if there is any hope of a resolution
in future Android version. The problem seems to arise from
BitmapFactory.decodeFile() . I've communicated with other developers
that seem to have almost the exact same problem. I'd like to at least
know if this is on the radar as a bug, and if there is any chance it
will be dealt with in a future version of Android. Thanks

Mark




On Jan 8, 3:29pm, Romain Guy <romain...@google.com> wrote:
--~--~---------~--~----~------------~-------~--~----~



OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by nickthecook » Sun, 11 Jan 2009 23:29:49 GMT


 'm still seeing this problem as well. I can boot my phone, start my
app, load a single image (~300k) and have this error. I'm loading
images with the BitmapFactory.decodeByteArray() method, which calls
BitmapFactory.nativeDecodeByteArray().

What is interesting is that after I added a background thread to my
app to load and process images, I had a bug where changing the
orientation of the screen caused another thread to be started. As soon
as two of my threads were in BitmapFactory.nativeDecodeByteArray() at
the same time, this method would attempt to allocate over 6MB of
memory, and I would get the error.

E/dalvikvm-heap( 1204): 6291456-byte external allocation too large for
this process.
E/ ( 1204): VM won't let us allocate 6291456 bytes
D/skia ( 1204): xxxxxxxxxxxxxxxxxxxx allocPixelRef failed
W/dalvikvm( 1204): threadid=15: thread exiting with uncaught exception
(group=0x40013e28)
E/AndroidRuntime( 1204): Uncaught handler: thread Thread-12 exiting
due to uncaught exception
E/AndroidRuntime( 1204): java.lang.OutOfMemoryError: bitmap size
exceeds VM budget
E/AndroidRuntime( 1204): at
android.graphics.BitmapFactory.nativeDecodeByteArray(Native Method)
E/AndroidRuntime( 1204): at
android.graphics.BitmapFactory.decodeByteArray(BitmapFactory.java:234)
E/AndroidRuntime( 1204): at
android.graphics.BitmapFactory.decodeByteArray(BitmapFactory.java:247)
E/AndroidRuntime( 1204): at
org.hopto.group18.postbot.Image.loadFileContents(Image.java:85)
E/AndroidRuntime( 1204): at org.hopto.group18.postbot.EditPost$20.run
(EditPost.java:800)
E/AndroidRuntime( 1204): at java.lang.Thread.run(Thread.java:935)

I'm using 500k buffers (down from 1MB, down from 1.5MB in an effort to
avoid OOMEs) to load images, the images themselves are ~300k (taken
with the phone's camera). I can't imagine why it is trying to allocate
6MB.

I have fixed my thread issue (even when not changing orientation this
issue occurs), and I am using locking to prevent two of my threads
from using this method at the same time, but I still see this error,
although less frequently.

It seems to come and go: sometimes I can't seem to load a single image
for a period of a minute or two, and then the problem will go away. Is
it possible that these errors can be the result of concurrent access
to this native method by my app and other apps?

On Jan 8, 7:05pm, Mark K <mark.ka...@gmail.com> wrote:
--~--~---------~--~----~------------~-------~--~----~



OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by nickthecook » Tue, 13 Jan 2009 19:46:08 GMT


 oes anyone know why this method would need to allocate 6MB? When this
issue occurs, it is always trying to allocate the same amount of
memory to the byte. It occurs with different images, of different
sizes. I load the file contents to a byte array and try to decode this
array into a Bitmap.

Here are two log excerpts in which the "LENGTH" message is showing the
length of the byte array from which I am trying to construct the
Bitmap:

D/Image ( 5480): LENGTH: 363525
E/dalvikvm-heap( 5480): 6291456-byte external allocation too large for
this process.
E/ ( 5480): VM won't let us allocate 6291456 bytes
D/skia ( 5480): xxxxxxxxxxxxxxxxxxxx allocPixelRef failed
W/dalvikvm( 5480): threadid=15: thread exiting with uncaught exception
(group=0x40013e28)
E/AndroidRuntime( 5480): Uncaught handler: thread Thread-9 exiting due
to uncaught exception
E/AndroidRuntime( 5480): java.lang.OutOfMemoryError: bitmap size
exceeds VM budget
E/AndroidRuntime( 5480): at
android.graphics.BitmapFactory.nativeDecodeByteArray(Native Method)
E/AndroidRuntime( 5480): at
android.graphics.BitmapFactory.decodeByteArray(BitmapFactory.java:234)
E/AndroidRuntime( 5480): at
android.graphics.BitmapFactory.decodeByteArray(BitmapFactory.java:247)
E/AndroidRuntime( 5480): at
org.hopto.group18.postbot.Image.loadFileContents(Image.java:88)
E/AndroidRuntime( 5480): at org.hopto.group18.postbot.EditPost$20.run
(EditPost.java:806)
E/AndroidRuntime( 5480): at java.lang.Thread.run(Thread.java:935)

...

D/Image ( 5450): LENGTH: 391154
E/dalvikvm-heap( 5450): 6291456-byte external allocation too large for
this process.
E/ ( 5450): VM won't let us allocate 6291456 bytes
D/skia ( 5450): xxxxxxxxxxxxxxxxxxxx allocPixelRef failed
W/dalvikvm( 5450): threadid=15: thread exiting with uncaught exception
(group=0x40013e28)
E/AndroidRuntime( 5450): Uncaught handler: thread Thread-11 exiting
due to uncaught exception
E/AndroidRuntime( 5450): java.lang.OutOfMemoryError: bitmap size
exceeds VM budget
E/AndroidRuntime( 5450): at
android.graphics.BitmapFactory.nativeDecodeByteArray(Native Method)
E/AndroidRuntime( 5450): at
android.graphics.BitmapFactory.decodeByteArray(BitmapFactory.java:234)
E/AndroidRuntime( 5450): at
android.graphics.BitmapFactory.decodeByteArray(BitmapFactory.java:247)
E/AndroidRuntime( 5450): at
org.hopto.group18.postbot.Image.loadFileContents(Image.java:88)
E/AndroidRuntime( 5450): at org.hopto.group18.postbot.EditPost$20.run
(EditPost.java:806)
E/AndroidRuntime( 5450): at java.lang.Thread.run(Thread.java:935)


I'm certainly open to the possibility that this is my fault, but if so
I'd like to know what I'm doing wrong, or if anyone is looking at the
native code involved for problems.

Thanks!

On Jan 11, 10:29am, nickthecook <nickthec...@gmail.com> wrote:
--~--~---------~--~----~------------~-------~--~----~



OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by blindfold » Tue, 13 Jan 2009 21:21:48 GMT


 Sounds like your have ~300 KB JPEG-compressed images at the standard
G1 resolution of 2048 * 1536. At 2 bytes per pixel (using RGB_565 or
ARGB_4444 format) this will in your phone expand into 2048 * 1536 * 2
= 6291456 bytes uncompressed. That's a sizable chunk of memory.

Regards




--~--~---------~--~----~------------~-------~--~----~



OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by nickthecook » Wed, 14 Jan 2009 11:27:46 GMT


 Interesting!

I'm usually able to load these images without a problem. Maybe 1 in 5
loads fails. Since they are all the same size, I would expect all
calls to fail like this, or none, but that number is definitely not a
coincidence.

Anyway, I'm now using the version of decodeByteArray that takes
options with inSampleSize = 2, and can't get it to crash no matter how
many images I try to process in a row, so the problem is gone for now,
at least.

Thanks for the insight!




--~--~---------~--~----~------------~-------~--~----~



OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by Rohit » Thu, 15 Jan 2009 08:32:29 GMT


 If I want to set the background resource of a view with a large PNG,
what is the best way to do it? Right now I just call
setBackgroundResource with the id of the resource eg.
R.drawable.wallpaper_news. Is there a better way to do it using
decodeByteArray? I have a couple of views to set the background for.
Which method is it best to do it in? Is dispatchDraw a good place?

Rohit






--~--~---------~--~----~------------~-------~--~----~



OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by ad » Sun, 25 Jan 2009 21:10:50 GMT


 ES YES YES!!!
I've found solution for that.
It's tricky but it works.
Place that on the begining of your code.

try{
while (true){
Bitmap tmpBitmap = Bitmap.createBitmap(320,
4800,
Config.ARGB_8888);
}

}catch(Throwable e){
e.printStackTrace();
System.out.println("CATCHED !!!!");

}

I was fighting with that about 4 days.
Hope anyone is happy now.

Regards,
avram.

On Dec 15 2008, 8:29pm, Mark K <mark.ka...@gmail.com> wrote:
--~--~---------~--~----~------------~-------~--~----~



OutOfMemoryError BitmapFactory.nativeDecodeByteArray inside Threads

by ad » Sun, 25 Jan 2009 21:23:38 GMT


 YES YES YES!!!
I've found solution for that bug.
It's tricky but it works.
Place that on the begining of your code.

                try{
                                Bitmap tmpBitmap = Bitmap.createBitmap
(3200, 4800,
Config.ARGB_8888);
                }catch(Throwable e){
                        e.printStackTrace();
                        System.out.println("CATCHED !!!!");

                }

I was fighting with that about 4 days.
Hope anyone is happy now, that was hell.

Regards,
avram.
--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. Segmentation fault when loading a certain class from an OSGi framework under Android 2.2 & 2.3

Hello,

... I'm afraid that asking in this group might be the last change to
get an idea how to solve the problem I'm currently facing - I have not
found any solution when searching the web... :-(

I face the following problem: I try to develop an application in an
OSGi framework under Android (resp., in an Android Emulator under
Windows 7). Generally, the OSGi framework (Apache Felix) works fine,
all the services of the installed bundles are registered. When I now
start a client bundle which wants to use a particular one of the
installed services, I get a segmentation fault when I try to retrieve
the service from the framework, and the OSGi framework simply crashes.
Other services can be retrieved & used without any problems. I already
found out that this must be somehow in relation to the fact that the
OSGi service uses a javax.security.auth.Subject in some of its method
signatures; it seems as if the Dalvik VM has a problem with loading
this class in this particular context (I also wrote some other test
code (by means of OSGi bundles) which for example creates an instance
of a Subject - in this case, everything works fine).

Here is an excerpt from the log; the problem appear (I think) in the
7th line:

++++++++++++++++++++++++++++++++++
05-09 13:20:08.740: DEBUG/dalvikvm(13668): DEX prep './felix-cache/
bundle10/version10.0/bundle.jar': unzip in 10ms, rewrite 153ms
05-09 13:20:19.819: DEBUG/dalvikvm(13668): DexOpt: --- BEGIN
'bundle.jar' (bootstrap=0) ---
05-09 13:20:19.929: DEBUG/dalvikvm(13750): DexOpt: load 10ms, verify
0ms, opt 3ms
05-09 13:20:19.939: DEBUG/dalvikvm(13668): DexOpt: --- END
'bundle.jar' (success) ---
05-09 13:20:19.939: DEBUG/dalvikvm(13668): DEX prep './felix-cache/
bundle34/version0.0/bundle.jar': unzip in 1ms, rewrite 116ms
05-09 13:20:20.009: DEBUG/dalvikvm(13668): GC_FOR_MALLOC freed 10683
objects / 957840 bytes in 54ms
05-09 13:20:20.079: WARN/dalvikvm(13668): VFY: unable to find class
referenced in signature (Ljavax/security/auth/Subject;)
05-09 13:20:20.379: INFO/DEBUG(31): *** *** *** *** *** *** *** ***
*** *** *** *** *** *** *** ***
05-09 13:20:20.379: INFO/DEBUG(31): Build fingerprint: 'generic/sdk/
generic/:2.2/FRF91/43546:eng/test-keys'
05-09 13:20:20.389: INFO/DEBUG(31): pid: 13668, tid: 13679  >>> /
system/bin/dalvikvm <<<
05-09 13:20:20.389: INFO/DEBUG(31): signal 11 (SIGSEGV), fault addr
00000024
05-09 13:20:20.399: INFO/DEBUG(31):  r0 00000000  r1 4013fc48  r2
00011074  r3 80087fc4
05-09 13:20:20.399: INFO/DEBUG(31):  r4 80088d1c  r5 400fb210  r6
00000000  r7 41f695f1
05-09 13:20:20.399: INFO/DEBUG(31):  r8 80013b00  r9 400fb210  10
401abeb0  fp 0002e0c8
05-09 13:20:20.409: INFO/DEBUG(31):  ip 80088098  sp 422e1d38  lr
8005ee23  pc 8005cdce  cpsr 20000030
05-09 13:20:20.449: INFO/DEBUG(31):          #00  pc 0005cdce  /system/
lib/libdvm.so
05-09 13:20:20.449: INFO/DEBUG(31):          #01  pc 0005ee1e  /system/
lib/libdvm.so
05-09 13:20:20.449: INFO/DEBUG(31):          #02  pc 0005ee8c  /system/
lib/libdvm.so
05-09 13:20:20.449: INFO/DEBUG(31):          #03  pc 0005ef6c  /system/
lib/libdvm.so
05-09 13:20:20.459: INFO/DEBUG(31):          #04  pc 0005f13e  /system/
lib/libdvm.so
05-09 13:20:20.459: INFO/DEBUG(31):          #05  pc 00017c60  /system/
lib/libdvm.so
05-09 13:20:20.459: INFO/DEBUG(31):          #06  pc 0001e8c4  /system/
lib/libdvm.so
05-09 13:20:20.469: INFO/DEBUG(31):          #07  pc 0001d790  /system/
lib/libdvm.so
05-09 13:20:20.469: INFO/DEBUG(31):          #08  pc 00053eec  /system/
lib/libdvm.so
05-09 13:20:20.469: INFO/DEBUG(31):          #09  pc 00054102  /system/
lib/libdvm.so
05-09 13:20:20.479: INFO/DEBUG(31):          #10  pc 0004825a  /system/
lib/libdvm.so
05-09 13:20:20.479: INFO/DEBUG(31):          #11  pc 0001103c  /system/
lib/libc.so
05-09 13:20:20.479: INFO/DEBUG(31):          #12  pc 00010b20  /system/
lib/libc.so
05-09 13:20:20.479: INFO/DEBUG(31): code around pc:
05-09 13:20:20.489: INFO/DEBUG(31): 8005cdac 10831a98 43584803
46c04770 0002b228
05-09 13:20:20.489: INFO/DEBUG(31): 8005cdbc 00000374 aaaaaaab
4b12b510 2900447b
05-09 13:20:20.489: INFO/DEBUG(31): 8005cdcc 6a42d01e 062424b0
4c0f1912 4c0f591b
05-09 13:20:20.489: INFO/DEBUG(31): 8005cddc 681b3394 dc0442a2
d0022b00 181800d0
05-09 13:20:20.499: INFO/DEBUG(31): 8005cdec 3050e000 3b016843
e007009a 58a46804
05-09 13:20:20.499: INFO/DEBUG(31): code around lr:
05-09 13:20:20.499: INFO/DEBUG(31): 8005ee00 f7ff1c07 4c14ffe9
48141c06 5824447c
05-09 13:20:20.499: INFO/DEBUG(31): 8005ee10 6820348c f7b43014
6ce9e982 f7fd1c30
05-09 13:20:20.499: INFO/DEBUG(31): 8005ee20 9001ffd1 30146820
ec66f7b4 20019b01
05-09 13:20:20.499: INFO/DEBUG(31): 8005ee30 d10e2b00 1c386ce9
ffcef7ff d0011e04
05-09 13:20:20.509: INFO/DEBUG(31): 8005ee40 d1032e00 ff20f7e7
63012100 42501b32
05-09 13:20:20.509: INFO/DEBUG(31): stack:
05-09 13:20:20.509: INFO/DEBUG(31):     422e1cf8  401f1180  /dev/
ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.509: INFO/DEBUG(31):     422e1cfc  8006caa4  /system/
lib/libdvm.so
05-09 13:20:20.509: INFO/DEBUG(31):     422e1d00  00000002
05-09 13:20:20.519: INFO/DEBUG(31):     422e1d04  00000000
05-09 13:20:20.519: INFO/DEBUG(31):     422e1d08  401f1180  /dev/
ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.519: INFO/DEBUG(31):     422e1d0c  0009eb00  [heap]
05-09 13:20:20.519: INFO/DEBUG(31):     422e1d10  41f695f1  /data/
dalvik-cache/mnt@sdcard@test@felix-osgi@.@felix-
cache@bundle10@version1...@bundle.jar@classes.dex
05-09 13:20:20.519: INFO/DEBUG(31):     422e1d14  401692c8  /dev/
ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.519: INFO/DEBUG(31):     422e1d18  00011074  [heap]
05-09 13:20:20.529: INFO/DEBUG(31):     422e1d1c  afd10510  /system/
lib/libc.so
05-09 13:20:20.529: INFO/DEBUG(31):     422e1d20  80088d1c  /system/
lib/libdvm.so
05-09 13:20:20.529: INFO/DEBUG(31):     422e1d24  400fb210  /dev/
ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.529: INFO/DEBUG(31):     422e1d28  00000000
05-09 13:20:20.529: INFO/DEBUG(31):     422e1d2c  41f695f1  /data/
dalvik-cache/mnt@sdcard@test@felix-osgi@.@felix-
cache@bundle10@version1...@bundle.jar@classes.dex
05-09 13:20:20.539: INFO/DEBUG(31):     422e1d30  df002777
05-09 13:20:20.539: INFO/DEBUG(31):     422e1d34  e3a070ad
05-09 13:20:20.539: INFO/DEBUG(31): #00 422e1d38  80088d1c  /system/
lib/libdvm.so
05-09 13:20:20.539: INFO/DEBUG(31):     422e1d3c  8005ee23  /system/
lib/libdvm.so
05-09 13:20:20.549: INFO/DEBUG(31): #01 422e1d40  00028850  [heap]
05-09 13:20:20.549: INFO/DEBUG(31):     422e1d44  0004a340  [heap]
05-09 13:20:20.549: INFO/DEBUG(31):     422e1d48  00000000
05-09 13:20:20.549: INFO/DEBUG(31):     422e1d4c  400fb210  /dev/
ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.549: INFO/DEBUG(31):     422e1d50  410ceefc  /dev/
ashmem/dalvik-LinearAlloc (deleted)
05-09 13:20:20.549: INFO/DEBUG(31):     422e1d54  401dcd08  /dev/
ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.549: INFO/DEBUG(31):     422e1d58  400fb210  /dev/
ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.559: INFO/DEBUG(31):     422e1d5c  8005ee91  /system/
lib/libdvm.so
05-09 13:20:21.239: INFO/BootReceiver(59): Copying /data/tombstones/
tombstone_09 to DropBox (SYSTEM_TOMBSTONE)
05-09 13:20:21.399: DEBUG/dalvikvm(59): GC_FOR_MALLOC freed 2764
objects / 477792 bytes in 155ms
++++++++++++++++++++++++++++++++++


Does anyone have an idea what might be the reason for this problem,
and - of course even more important - has an idea how this problem
might be solved? I'm working on this for several days, but at the
moment, I have no idea what to do any more...

Btw: in case that someone needs some more information just ask!

Thank you in advance, and best regards from Germany,
Sierra

-- 

2. C Sharp Basics

To know more about C Sharp Basics with Examples in very easy way then
please visit:

http://csharpexpress.blogspot.com/

-- 

3. Boot Camp: Mobile Application Development

4. android.view.WindowManager$BadTokenException

5. emulator too slow

6. [WTB] Samsung Galaxy Tab 1 (7inch) second

7. HELP! O1 ane masuk emergency mode