Hi fadden,
Now I met a problem with System.exit() as below:
I tried with my simple test app:
public class Test
{
static class SimpleThread1 implements Runnable {
public void run() {
try {
System.out.println("Start simple thread 1 with
thread ID==" + this.getId() + "and name==" + this.getName());
Thread.sleep(4000);
System.out.println("Call System.exit()");
System.exit(0);
}catch(InterruptedException e) {
System.out.println("InterruptedException 1");
}
}
}
static class SimpleThread2 implements Runnable {
public void run() {
try {
System.out.println("Start simple thread 2 with
thread ID==" + this.getId() + "and name==" + this.getName());
Thread.sleep(50000);
}catch(InterruptedException e) {
System.out.println("InterruptedException 2");
}
}
}
public static void main(String[] args) {
try {
sp1 = new Thread(new SimpleThread1());
sp1.start();
} catch (Exception e) {
System.out.println("Failed to create subthread : " +
e.getMessage());
}
try {
sp2 = new Thread(new SimpleThread2());
sp2.start();
} catch (Exception e) {
System.out.println("Failed to create subthread 222222 : "
+ e.getMessage());
}
}
}
I have 2 threads sp1, sp2. When sp1 thread start running, after sleep
4s, it will call System.exit(0) to exit VM. Expected result is that
Dalvik will exit normally but in my case Dalvik has been crashed. I
tried to debug and found that when call System.exit(0), it will call
to function exit() in native. As my debug, Dalvik crashed dute to it
go to
static void threadExitCheck(void* arg)
{
Thread* thread = (Thread*) arg;
LOGI("In threadExitCheck %p\n", arg);
assert(thread != NULL);
if (thread->status != THREAD_ZOMBIE) {
/* TODO: instead of failing, we could call
dvmDetachCurrentThread() */
LOGE("Native thread exited without telling us\n");
dvmAbort();
}
}
and I found that it called to dvmAbort and my board automatically
reboot. With my debug, thread status in above function is
THREAD_RUNNING so it goes to if block and call dvmAbort.
I do not why it goes to if block and cause dvmAbort call. If it does
not call dvmAbort() does Dalvik terminates successfully? What is
condition for Dalvik VM terminates successfully when call System.exit
().
I have tried to comment out dvmAbort() function but Dalvik is hang.
Would you let me know what is the issue that I am meeting and how to
resolve it? ( I also do not know whether the function exit() call is
right on Vxworks or not)
Thanks so much
Mercury
On Jul 17, 11:36 pm, Mercury <bao...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
