Hi fadden, I'll try to check some things that you advised to find out the issue. I'll update if I found some things.
Thank you for your kind help. Sincerely, BR On Jul 10, 4:37 am, fadden <[email protected]> wrote: > On Jul 8, 6:06 pm, Mercury <[email protected]> wrote: > > > > > I am trying to run my small sample app. It only call System.exit(0) in > > main function. > [...] > > stack trace information: > > SP:0x8ee01690(unknown stack base:0x8fa00000) > > 0x8006f5b0:bfill + 0x68 > > 0x80e56980:memset + 0x20 -> bfill() > > 0x80c4320c:mspace_malloc_stats + 0x1b4 -> memset() > > 0x80c43308:create_mspace_with_base + 0x68 -> mspace_malloc_stats() > > 0x80c4341c:create_contiguous_mspace_with_name + 0xec -> > > create_mspace_with_base() > > 0x80cbe390:dvmHeapSourceShutdown + 0xe0 -> > > create_contiguous_mspace_with_name() > > 0x80cbeb5c:dvmHeapSourceStartup + 0xa4 -> dvmHeapSourceShutdown() > > 0x80c73ed8:dvmHeapStartup + 0x28 -> dvmHeapSourceStartup() > > 0x80ca16a8:dvmStartup + 0xa0 -> dvmHeapStartup() > > First off, I think your stack trace is a bit off -- > dvmHeapSourceStartup doesn't call dvmHeapSourceShutdown. > > If we make some assumptions, it looks like you're failing during VM > startup, specifically when it's allocating and initializing the > virtual heap. This strongly suggests there's a problem with your > ashmem driver, which might also explain why it works the first time > and not the second. (Might also explain why System.gc() was blowing > up in your other message.) > > The virtual heap is created in a memory-mapped ashmem region, so if > something is wrong with the way the driver works you're going to have > trouble. A bad kernel driver would also explain why a problem in user > mode is causing the board to reboot. --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
