Hi fadden, When porting Dalvik on Vxworks, due to Vxwork does not support mmap and munmap function so I tried to replace them with functions malloc/ free and I had trouble with System.gc() as you and me discussed in previous messages.
Now I tried to replace malloc by calloc and it seems that it worked correctly. I tried to call System.gc() with only 2MB. It can work well and I can start Dalvik again after it exits from first call. I'll inform to you if I found some things more. I met another problem and I'll post it in another message. If you know about it, I am very happy if I receive your reply. Thank you On Jul 10, 6:37 pm, Mercury <bao...@gmail.com> wrote: > 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 <fad...@android.com> wrote: > > > On Jul 8, 6:06 pm, Mercury <bao...@gmail.com> wrote: > > > > I am trying to run my small sample app. It only callSystem.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: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
