help with alternative to System.exit

[bpedman]

Hey everyone,

So, I have started testing on a product that is new to me. The code
for the gui is using System.exit which kills the whole VM and so I
cant run more than one test...I am trying to figure out a way to
remove this but have been unsucessful. When I just remove the
System.exit() line the program will never exit by itself. I looked at
the java docs and found this:

With the current implementation, AWT terminates all its helper threads
allowing the application to exit cleanly when the following three
conditions are true:

* There are no displayable AWT or Swing components.
* There are no native events in the native event queue.
* There are no AWT events in java EventQueues.
<http://java.sun.com/javase/6/docs/api/java/awt/doc-files/
AWTThreadIssues.html#Autoshutdown>

So, I replace System.exit() with this:

Window[] activeWindows = Window.getWindows();
for (int i=0; i<activeWindows.length; i++) {
activeWindows[i].dispose();
activeWindows[i] = null;
}
EventQueue eventQueue = Toolkit.getDefaultToolkit
().getSystemEventQueue();
while(eventQueue.peekEvent() != null){
eventQueue.getNextEvent()
}

And it still sits there and waits for something...is there something
else I need to do???

Thanks for any help

-Brandon

[Simeon Fitch]

Have you tried looking at the permissions system to "ungrant" permission to call System.exit() (which will result in an exception you could catch).

Simeon

On Fri, Nov 6, 2009 at 5:29 PM, bpedman <bpe...@gmail.com> wrote:

Hey everyone,

So, I have started testing on a product that is new to me. The code
for the gui is using System.exit which kills the whole VM and so I
cant run more than one test...I am trying to figure out a way to
remove this but have been unsucessful. When I just remove the
System.exit() line the program will never exit by itself. I looked at
the java docs and found this:

...

[Simeon Fitch]

PS: This looks like a possible solution:

https://www.securecoding.cert.org/confluence/display/java/EXC04-J.+Prevent+against+inadvertent+calls+to+System.exit()+or+forced+shutdown

[Andriy Tsykholyas]

Hi,

as I understand to exit the application without call to System.exit()
you must ensure 2 things:
1) all windows are disposed (you can use Window.DISPOSE_ON_CLOSE for
this purpose);
2) no *live* thread is running (you can use daemon threads for
background tasks).
Due to all your windows are probably disposed, I suspect there is at
least one non-daemon thread running.

best regards

Andriy

[bpedman]

>https://www.securecoding.cert.org/confluence/display/java/EXC04-J.+Prevent+against+inadvertent+calls+to+System.exit()+or+forced+shutdown

thanks, this looks like something I could use.

>2) no *live* thread is running (you can use daemon threads for background tasks).

I dont think there are any other threads running (I thought that too
and used http://www.exampledepot.com/egs/java.lang/ListThreads.html to
see all the threads and all that was running were some AWT related
threads).

I was looking a bit more at
http://java.sun.com/javase/6/docs/api/java/awt/doc-files/AWTThreadIssues.html#Autoshutdown

Apparently this is a bug in java that they are not going to fix.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4465537

We are using a JScrollPane and so I think that is causing the
problem...I think I will have to leave in the System.exit call, catch
the call (just for testing), and try to clean up as many references to
the GUI as possible so the next test can start as cleanly as
possible...

thanks for the help,

-Brandon

[Jean-Francois Poilpret]

Andriy Tsykholyas wrote:
> Hi,
>
> as I understand to exit the application without call to System.exit()
> you must ensure 2 things:
> 1) all windows are disposed (you can use Window.DISPOSE_ON_CLOSE for
> this purpose);
> 2) no *live* thread is running (you can use daemon threads for
> background tasks).
> Due to all your windows are probably disposed, I suspect there is at
> least one non-daemon thread running.
>
>

Well be careful that Swing dialogs use a hidden window (can't remember
for which purpose exactly) that is reused for all dialogs and never
disposed of. Hence you have to find a ref to it and dispose it as well!
Also beware that this way of exiting a Swing application won't work with
Java Web Start :-(
If using Java Web Start for your app, you definitely have to call
System.exit().

I remember when I was using abbot (a couple of years ago), it had a
trick to intercept System.exit() and it was working fine with my app.
Maybe FEST should reuse the same trick?

Cheers

Jean-Francois

[Alex Ruiz]

I think Simeon's link is a possible solution for this issue. I'm thinking about providing a hook that doesn't allow the JVM to terminate on System.exit until all tests are executed.

Does that make sense? If it does, Brandon, can you please file a bug?

Jean-Francois, is this similar to Abbot's solution (I tried to find it but couldn't)

Thanks!
-Alex

[Jean-Francois Poilpret]

Alex Ruiz wrote:
> I think Simeon's link is a possible solution for this issue. I'm
> thinking about providing a hook that doesn't allow the JVM to
> terminate on System.exit until all tests are executed.
>
> Does that make sense? If it does, Brandon, can you please file a bug?
>
> Jean-Francois, is this similar to Abbot's solution (I tried to find it
> but couldn't)
>

Hi Alex, yes I just checked the link provided by Simeon and it uses the
same trick as in Abbot.
In abbot, there are several classes for this problem (IIRC they are a
bit hard to follow and understand):
- abbot.NoExitSecurityManager
- abbot.util.ThreadTerminatingSecurityManager (not sure where this one
is used)
- abbot.ExitException
- abbot.StepRunner (defines ExitHandler -derived from
NoExitSecurityManager- and sets it as SecurityManager
- abbot.ForkedStepRunner (refines further ExitHandler to notify -through
sockets- the script launcher in case of termination attempt)

Basically that's it! I think the most important for udnerstanding the
whole stuff are NoExitSecurityManager, ExitException and StepRunner. I
hope I haven't missed some other classes impacted by that.

Cheers

Jean-Francois

> <mailto:bped...@gmail.com>> wrote:
> >
>
>
>
>
>
> >

[Andriy Tsykholyas]

On Nov 7, 9:49 pm, bpedman <bped...@gmail.com> wrote:
>
> Apparently this is a bug in java that they are not going to fix.http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4465537
>

Bug 4465537 (http://bugs.sun.com/bugdatabase/view_bug.do?
bug_id=4465537) is a dupe of bug 4417287 (http://bugs.sun.com/
bugdatabase/view_bug.do?bug_id=4417287). And 4417287 was fixed in 1.4.
So, if you are not using pre 1.4, this bug should not affect you :)

You might want to use some profiler to find the problem. The one
bundled with netbeans is free and should be sufficient for this
purpose. You can check both threads and windows there.

best regards,

Andriy

[Alex Ruiz]

Thanks Jean-Francois! :)

Cheers,
-Alex

[Simeon Fitch]

You might want to use some profiler to find the problem. The one
bundled with netbeans is free and should be sufficient for this
purpose. You can check both threads and windows there.

A bit off-topic, but if you've not checked out the latest VisualVM (bundled with Java 6 except on MacOS) for profiling of all sorts. It's pretty sweet. It will run standalone and/or integrated with Netbeans or Eclipse (I think it's built on the Netbeans framework, so the integration is better there).

Here's a screencast of it in action.

Simeon

[bpedman]

Thanks, VisualVM is nice....

So, I am using it and I am still a bit lost as to what it could be,
here is an image of the running threads:

http://imagebin.ca/view/5fDJCbty.html

And then the thread dump shows:

http://pastebin.com/m28935f17

It looks like the only non-daemon threads are AWT-Shutdown, AWT-
EventQueue-0, DestroyJavaVM, and FlushBufferTimerTask

Not sure what the FlushBufferTimerTask is, Any thoughts?

Thanks,

-Brandon

On Nov 8, 12:36 pm, Simeon Fitch <simeon.fi...@mseedsoft.com> wrote:
> > You might want to use some profiler to find the problem. The one
> > bundled with netbeans is free and should be sufficient for this
> > purpose. You can check both threads and windows there.
>
> A bit off-topic, but if you've not checked out the latest

> VisualVM<https://visualvm.dev.java.net/> (bundled

> with Java 6 except on MacOS) for profiling of all sorts. It's pretty sweet.
> It will run standalone and/or integrated with Netbeans or Eclipse (I think
> it's built on the Netbeans framework, so the integration is better there).
>

> Here's a screencast<http://e.blip.tv/scripts/flash/showplayer.swf?file=http://blip.tv/rss...>of
> it in action.
>
> Simeon

[Simeon Fitch]

Brandon,

I'm not quite sure what it is that you are asking; the thread dumps look perfectly healthy to me. Are you trying to figure out who's calling System.exit()? Or the opposite (why the process isn't quitting)?

Simeon