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
-~----------~----~----~----~------~----~------~--~---

Reply via email to