Sorry to respond to my own email, but the problem is a known Java bug
http://developer.java.sun.com/developer/bugParade/bugs/4030718.html
Says:
> A program which calls the static method getDefaultToolkit()in
> class Toolkit won't terminate. The following is a simplest
> java source code for this bug.
>
> import java.awt.*;
> class Test {
> public static void main(String[] args) {
> Toolkit.getDefaultToolkit();
> }
> }
>
> After starting this program, it should return to OS. However,
> it hangs there forever.
I verified that this bug occurs under JDK1.3.1_06, but does
not occur in JDK1.4.1
In a Ptolemy II 2.0.1 tree with JDK1.3.1_06, I ran
$PTII/bin/ptexecute -debug stdouttest.xml
and then started up jdb within emacs with M-x jdb, which
ran jdb -attach javadebug
And then I did
stop in java.awt.Toolkit.getDefaultToolkit()
cont
The program stopped, and I did
where
and got
[1] java.awt.Toolkit.getDefaultToolkit (Toolkit.java:491)
[2] java.awt.SystemColor.updateSystemColors (SystemColor.java:337)
[3] java.awt.SystemColor.<clinit> (SystemColor.java:330)
[4] java.lang.Class.forName0 (native method)
[5] java.lang.Class.forName (Class.java:115)
[6] javax.swing.plaf.basic.BasicLookAndFeel.class$(BasicLookAndFeel.java:49)
[7] javax.swing.plaf.basic.BasicLookAndFeel.loadSystemColors
(BasicLookAndFeel.java:182)
[8]
com.sun.java.swing.plaf.windows.WindowsLookAndFeel.initSystemColorDefaults
(WindowsLookAndFeel.java:153)
[9] javax.swing.plaf.basic.BasicLookAndFeel.getDefaults (BasicLookAndFeel.java:56)
[10] javax.swing.UIManager.setLookAndFeel (UIManager.java:356)
[11] javax.swing.UIManager.setLookAndFeel (UIManager.java:383)
[12] ptolemy.actor.gui.MoMLApplication.<init> (MoMLApplication.java:128)
[13] ptolemy.actor.gui.PtExecuteApplication.<init> (PtExecuteApplication.java:75)
[14] ptolemy.actor.gui.PtExecuteApplication.main (PtExecuteApplication.java:112)
main[1]
and the resulting stacktrace indicated that we
were calling getDefaultToolkit from the line in ptolemy/actor/gui/MoMLApplication.java:
// The Java look & feel is pretty lame, so we use the native
// look and feel of the platform we are running on.
// NOTE: This creates the only dependence on Swing in this
// class. Should this be left to derived classes?
try {
---> UIManager.setLookAndFeel(
UIManager.getSystemLookAndFeelClassName());
} catch (Exception e) {
// Ignore exceptions, which only result in the wrong look
and feel.
}
If I commented out those lines, then the bug went away
and the example worked fine under JDK1.3.1_06
Note that the PrintThreads methods also end up invoking
getDefaultToolkit(), so if you added code that calls a PrintThreads
method, then you should remove that code.
I tried to use Eclipse to set a breakpoint in getDefaultToolkit,
but I could not figure out how to use Eclipse to set a breakpoint in
a class defined within the JVM. I'm sure it can be done in Eclipse,
but it was not obvious.
BTW - another workaround is to use the -test argument which
calls System.exit after two seconds:
$PTII/bin/ptexecute -test stdouttest.xml
or
java -classpath "$PTII;$PTII/lib/diva.jar" ptolemy.actor.gui.PtExecuteApplication
-test stdouttest.xml
-Christopher
I wrote:
> Sorry for the delay, I was away last week.
>
> I took a look at this
>
> I could not reproduce the problem under
> PtII 2.1devel Windows 2000 JDK1.4.1_01-b01
> CYGWIN_NT-5.0 MOWAT-171 1.3.10(0.51/3/2) 2002-02-25 11:14 i686
> PtII 2.1devel Windows XP JDK1.4.1-b21
> CYGWIN_NT-5.1 DOPLAP03 1.3.10(0.51/3/2) 2002-02-25 11:14 i686
> PtII 2.0.1 Windows XP JDK1.4.1-b21
> CYGWIN_NT-5.1 DOPLAP03 1.3.10(0.51/3/2) 2002-02-25 11:14 i686
>
>
> However, under
> PtII 2.0.1 WindowsXP JDK1.3.1_04 and JDK1.3.1_06
> CYGWIN_NT-5.1 DOPLAP03 1.3.10(0.51/3/2) 2002-02-25 11:14 i686
>
> Your example hangs after running and does not return to stdout
>
> It looks like the problem is solved by JDK1.4.1. However, JDK1.4.1
> will not work with codegen in Ptolemy II 2.0.1. There are a couple
> of issues, one involving a change in the byte codes generated
> by the Java compiler, the other involving a bug in Soot.
> If you do not require codegen, then you could try JDK1.4.1
>
> Other than that, we could poke around and see if there is a workaround
> to the bug under JDK1.3.1. I suspect that either a thread is not
> ending or that perhaps we are keeping a file descriptor open
>
> ptII/util/testsuite/PrintThreads.java might be useful here, or
> running the example under a debugger might help
> I'm rebuilding a PtII 2.0.1 tree under JDK1.3.1_06, and I'll see
> if there is any obvious difference between running under JDK1.3.1_06
> and JDK1.4.1
>
> -Christopher
>
> --------
>
>
> Ok, I was not clear.
> Let me try further.
> Attached is a very simple example that simple creates data on standard out.
>
> When I run :
>
> java -classpath "$PTII:$PTII/lib/diva.jar" ptolemy.actor.gui.PtExecuteAppli
> cation ./greg_simple.xml
>
> on an Linux platform the command executes and control is returned to the ba
> sh shell.
>
> When I run:
>
> java -classpath "$PTII;$PTII/lib/diva.jar" ptolemy.actor.gui.PtExecuteAppli
> cation ./greg_simple.xml
>
> (only change is ; instead of :)
> on a CYGWIN platform, the command executes (i.e output comes to standard ou
> t), BUT CONTROL
> IS NOT RETURNED to the bash shell
>
> My uname -a on the CYGWIN results in
>
> CYGWIN_NT-5.0 RUSS-LAPTOP2 1.3.12(0.54/3/2) 2002-07-06 02:16 i686 unknown
>
> Note that your example brings up a display, mine does not.
> And, yours does not terminate either.
>
> Greg Rohling
>
>
>
>
> [EMAIL PROTECTED] wrote:
>
> > Hmm.
> > cd $PTII
> > $PTII/bin/ptexecute ptolemy/domains/sdf/demo/Butterfly/Butterfly.xml
> >
> > works for me - the Butterfly comes up.
> > I'm running under Windows XP SP1 and uname -a returns:
> > CYGWIN_NT-5.1 EDALAP03 1.3.12(0.54/3/2) 2002-07-06 02:16 i686 unknown
> >
> > I'm a little confused because you say that the command completes, but
> > command never comes back, but then you say that the java command is
> > never executed? It seems like there is a contradiction here.
> >
> > You could try running the command by hand by creating a simple shell
> > script that contains something like
> >
> > java -classpath "$PTII;$PTII/lib/diva.jar" ptolemy.actor.gui.PtExecuteApp
> lication ptolemy/domains/sdf/demo/Butterfly/Butterfly.xml
> >
> > and see if the problem is the shell script or PtExecuteApplication
> >
> > I think PtExecuteApplication requires the command line to contain
> > a file name that contains the model, so I'm not sure if it will
> > work reading a model from stdin.
> >
> > -Christopher
> >
> > --------
> >
> >
> >
> > I have been using ptexecute on a Linux platform to execute a
> > auto generated models output onto standard-out.
> >
> > When I try the same thing on a Windows/cygwin environment
> > the standard out completes, but control never comes
> > back to the terminal without a <ctrl> c.
> > A placed a set -x in the ptexecute script and found
> > that the java command is not executing.
> >
> > Any ideas about how to get control back?
> >
> > Greg Rohling
> >
> >
>
> <<Attachment deleted, see
>http://ptolemy.eecs.berkeley.edu/~cxh/tmp/stdouttest.xml.gz>>
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
