Issue1675

classification
Title: Jython exits prematurely when executing a file, thus killing Swing windows
Type: behaviour Severity: normal
Components: Core Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: zyasoft Nosy List: MrMeanie, alex.gronholm, otmarhumbel, pjenvey, scoder, zyasoft
Priority: urgent Keywords: patch

Created on 2010-11-07.23:55:40 by MrMeanie, last changed 2010-12-24.23:17:57 by pjenvey.

Files
File name Uploaded Description Edit Remove
swingtest.py MrMeanie, 2010-11-14.15:28:03 Very simple Swing program
unforce_exit-r7173.diff pjenvey, 2010-12-22.03:04:12
Messages
msg6231 (view) Author: Geoffrey French (MrMeanie) Date: 2010-11-07.23:55:39
When executing a Python file with the command line:

jython program.py

The Jython interpreter exits immediately with System.exit() upon finishing executing the script.
The result is that any Swing windows that are open are closed immediately, upon Jython reaching the end of the program (instead of waiting for the user to close them) - Swing applications cannot run normally.
msg6232 (view) Author: Geoffrey French (MrMeanie) Date: 2010-11-07.23:58:25
At the end of jython#run()  (org.jython.util package)
are the lines:

        interp.cleanup();
        if (opts.fixInteractive || opts.interactive) {
            System.exit(0);
        }


It seems that when running a file, opts.interactive has a value of true.
msg6233 (view) Author: Alex Grönholm (alex.gronholm) Date: 2010-11-08.01:00:50
Could you please show the script you tried to run?
msg6234 (view) Author: Alex Grönholm (alex.gronholm) Date: 2010-11-08.01:04:01
Nevermind, I tested with the binding example of jython-swingutils and it does not run either. This is borked.
msg6245 (view) Author: Jim Baker (zyasoft) Date: 2010-11-09.23:28:33
opts.interactive means, does the process that runs this code a console (a tty), irrespective if it's a script or not? In the past, we didn't correctly perform this a test. The main fix for RC2 was to correct this, so it would work with ipython. Naturally it's causing issues on code that relied on this broken functionality, as seen here at the end of #run.

We need some sort of fix for RC3.
msg6247 (view) Author: Oti Humbel (otmarhumbel) Date: 2010-11-14.09:30:25
After many hours of testing, i came to the conclusion that this is NOT reproducible with Runtime.exec() (or it's higher level abstractions Popen and subprocess). 
The reason is that java's Runtime.exec() always waits until the last Thread has finished, regardles of the System.exit() in the jython run method.
msg6248 (view) Author: Oti Humbel (otmarhumbel) Date: 2010-11-14.09:46:57
The obvious workaround is to start jython with the -i flag
msg6249 (view) Author: Geoffrey French (MrMeanie) Date: 2010-11-14.15:28:03
The following code reproduces it:

from javax.swing import *

label = JLabel( 'Hello world' )
frame = JFrame()
frame.add( label )
frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE )

frame.show()


Also attached as a file.

Running it with 'jython swingtest.py' exits immediately, closing the window, instead of waiting for the user to close it.
Running it with 'jython -i swingtest.py' does not, but requires that Jython is closed manually from the jython prompt.


Commenting out the 'System.exit(0);' line in jython.java allows the program to run with 'jython swingtest.py' as one would expect it to.



My platform:

Windows Vista 64

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)

Jython: r7171
msg6250 (view) Author: Oti Humbel (otmarhumbel) Date: 2010-11-15.06:35:00
Geoffrey,
sorry for the confusion. Of course it is reproducible from the command line. What I meant is that it is very hard to reproduce in a unit test by calling the jython command from java.
msg6265 (view) Author: Stefan Behnel (scoder) Date: 2010-12-01.10:24:16
Here's a work-around that can be put at the end of a program's main application code:

    # work around Jython bug that kills Swing thread on main exit
    import threading
    while True:
        alive = False
        for thread in threading.enumerate():
            if not thread.isDaemon():
                alive = True
                thread.join(2)
        if not alive:
            sys.exit(0)
msg6290 (view) Author: Philip Jenvey (pjenvey) Date: 2010-12-22.03:04:12
Attached a patch with a potential fix. This passes the regrtest. Might this break anything else?

looking at r7161 (the orig IPython fix), it's doubtful that this patch would hurt IPython. Can someone try it with IPython or describe the IPython broken behavior prior to r7161?
msg6302 (view) Author: Philip Jenvey (pjenvey) Date: 2010-12-24.23:17:57
The patched ipython seems ok AFAICT with this patch. this doesn't touch the interactivity flag at all anyway, so we should be good. applied in r7177
History
Date User Action Args
2010-12-24 23:17:57pjenveysetstatus: open -> closed
resolution: fixed
messages: + msg6302
2010-12-22 03:04:12pjenveysetfiles: + unforce_exit-r7173.diff
keywords: + patch
messages: + msg6290
nosy: + pjenvey
2010-12-01 10:24:16scodersetnosy: + scoder
messages: + msg6265
2010-11-15 06:35:00otmarhumbelsetmessages: + msg6250
2010-11-14 15:28:03MrMeaniesetfiles: + swingtest.py
messages: + msg6249
2010-11-14 09:46:58otmarhumbelsetmessages: + msg6248
2010-11-14 09:30:25otmarhumbelsetnosy: + otmarhumbel
messages: + msg6247
2010-11-12 17:41:28zyasoftsetpriority: urgent
assignee: zyasoft
2010-11-09 23:28:33zyasoftsetnosy: + zyasoft
messages: + msg6245
2010-11-08 01:04:03alex.gronholmsetmessages: + msg6234
2010-11-08 01:00:51alex.gronholmsetnosy: + alex.gronholm
messages: + msg6233
2010-11-07 23:58:25MrMeaniesetmessages: + msg6232
2010-11-07 23:56:04MrMeaniesettype: behaviour
components: + Core
2010-11-07 23:55:40MrMeaniecreate