Re: [Sablevm-developer] sablevm hang

[Joseph P. <pa...@mc...>]

Yeah, i made that sounds confusing ;p  I meant to say that i have no 
problem using the AwtUtils.init... by itself, nor do i have a problem 
burying an awt class way down in a series of class instantiations 
(currently tried about 6 levels down).  

However, in the current code base (JXTA) if i remove the call to 
AwtUtils.init... the next call (which instantiates a class that displays a 
Frame)  hangs with the same problem and at VMObject.wait.  I'm not sure 
if i'm hitting a thread limit or what, it seems kind of odd that the same 
problem occurs regardless of whether or not i call AwtUtils.init or create 
a new Frame.

I'll try your suggestions below and post some results.

Thanks!
Joe

On Thu, 17 Jun 2004, Chris Pickett wrote:

> Joseph Paris wrote:
> > I've done some testing with sablevm and calling methods for awt, and i 
> > haven't had a problem.  For example, instantiating an AWT or Swing class 
> > from inside another class there were no problems.  If i remove that call 
> > in code, it then hangs on the instantiation of an AWT/Swing class one line 
> > later.
> 
> I'm sorry, I don't follow 100%.  Can you illustrate with code?
> 
>    The hang happens every time (and i've tried about 40+ times to
> > make sure ;p).  I'm really not sure why it would hang there, and i know 
> > there is no problem using Sun's jvm.
> 
> Okay.  That's very fortunate that it happens every time :)
> 
> > I'm not too familiar on how your vm works.  Do you create a thread per 
> > class that's loaded, etc?
> 
> There is one pthread per Java thread.
> 
>    I wish i had a more simple test case to work
> > with.  What are the relevant files i should be looking at?
> 
> Check out the staging versions of sablevm and sablevm-classpath (which 
> are fairly stable, but contain more recent updates than the tarballs). 
> You could also grab the latest nightly snapshots.  See:
> 
> http://devel.sablevm.org/wiki/Getting
> 
> As for relevant files ... well, there's Java stuff in sablevm-classpath, 
> and VM stuff in sablevm.  You might want to try
> 
> ./configure --enable-debugging-features --with-threading=switch
> 
> for the most safe mode.  The switch interpreter is easier to step 
> through with gdb.
> 
> I tried it with an older (roughly 1.1.4) sablevm-switch-debug and it 
> still hangs.  I changed the _svmf_dump_stack_trace() function to print 
> out internal frames, and I see:
> 
> stack_bottom_method
> (VMObject.java:-1)  java/lang/VMObject.wait  n
> (Object.java:445)  java/lang/Object.wait
> (EventQueue.java:98)  java/awt/EventQueue.getNextEvent
> (EventDispatchThread.java:64)  java/awt/EventDispatchThread.run
> (VMThread.java:116)  java/lang/VMThread.callRun
> (Thread.java:386)  java/lang/Thread.callRun
> (VirtualMachine.java:117)  java/lang/VirtualMachine.runThread
> vm_initiated_call_method
> stack_bottom_method
> 
> which at first glance suggests the other thread (at the top) never even 
> gets started properly.  I might be wrong, but it looks related to some 
> thread startup errors we were seeing earlier.  Etienne and Greg, I put 
> Joe's current test case with an added main method at:
> 
> http://www.sable.mcgill.ca/~cpicke/sablevm/AwtUtils.java
> 
>    I will
> > continue to try and replicate this problem in a more simple case.
> 
> Sure.  Basically every line or possibly funny syntax (e.g. anonymous 
> classes) that you can eliminate cuts down the problem.
> 
> Cheers,
> Chris
> 
>