You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Ralf Stuckert (JIRA)" <ji...@codehaus.org> on 2012/08/03 09:48:21 UTC
[jira] (SUREFIRE-897) System.exit() in ForkedBooter might hang due
to swing/windows bug
Ralf Stuckert created SUREFIRE-897:
--------------------------------------
Summary: System.exit() in ForkedBooter might hang due to swing/windows bug
Key: SUREFIRE-897
URL: https://jira.codehaus.org/browse/SUREFIRE-897
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Affects Versions: 2.12
Environment: Windows, Java 6,7
Reporter: Ralf Stuckert
Attachments: ForkedBooter.patch
Due to a bug in Swing on Windows (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7071160) the forked process may not respond to System.exit() in class ForkedBooter after excuting swing tests on windows. This leads to a hanging build, and the only way to resolve it, is to kill the hanging process.
After all, sending Runtime.halt() will always stop the process. But since this is not a clean shutdown (e.g. shutdown-hooks not running), this should not be the default behaviour.
As a workaround, you could start a daemon thread as a watchdog before calling System.exit().
The deamon sleeps for a certain time, let's say a minute. If it ever resumes from sleeping, it means that the JVM is still running, so the System.exit() was not completed in that time. Now it's time to call Runtime.halt() as a last exit.
We used this strategy to overcome the Swing bug (see attached patch).
I guess it would be nice, if the timeout would be configurable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-897) System.exit() in ForkedBooter might hang due
to swing/windows bug
Posted by "Kristian Rosenvold (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/SUREFIRE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305661#comment-305661 ]
Kristian Rosenvold edited comment on SUREFIRE-897 at 8/7/12 12:35 AM:
----------------------------------------------------------------------
Fixed in r1369951, thanks for the patch !
was (Author: krosenvold):
Ficed in r1369951, thanks for the patch !
> System.exit() in ForkedBooter might hang due to swing/windows bug
> -----------------------------------------------------------------
>
> Key: SUREFIRE-897
> URL: https://jira.codehaus.org/browse/SUREFIRE-897
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
> Affects Versions: 2.12
> Environment: Windows, Java 6,7
> Reporter: Ralf Stuckert
> Assignee: Kristian Rosenvold
> Fix For: 2.12.2
>
> Attachments: ForkedBooter.patch
>
>
> Due to a bug in Swing on Windows (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7071160) the forked process may not respond to System.exit() in class ForkedBooter after excuting swing tests on windows. This leads to a hanging build, and the only way to resolve it, is to kill the hanging process.
> After all, sending Runtime.halt() will always stop the process. But since this is not a clean shutdown (e.g. shutdown-hooks not running), this should not be the default behaviour.
> As a workaround, you could start a daemon thread as a watchdog before calling System.exit().
> The deamon sleeps for a certain time, let's say a minute. If it ever resumes from sleeping, it means that the JVM is still running, so the System.exit() was not completed in that time. Now it's time to call Runtime.halt() as a last exit.
> We used this strategy to overcome the Swing bug (see attached patch).
> I guess it would be nice, if the timeout would be configurable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-897) System.exit() in ForkedBooter might hang due
to swing/windows bug
Posted by "Kristian Rosenvold (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/SUREFIRE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Rosenvold closed SUREFIRE-897.
---------------------------------------
Resolution: Fixed
Fix Version/s: 2.12.2
Assignee: Kristian Rosenvold
Ficed in r1369951, thanks for the patch !
> System.exit() in ForkedBooter might hang due to swing/windows bug
> -----------------------------------------------------------------
>
> Key: SUREFIRE-897
> URL: https://jira.codehaus.org/browse/SUREFIRE-897
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
> Affects Versions: 2.12
> Environment: Windows, Java 6,7
> Reporter: Ralf Stuckert
> Assignee: Kristian Rosenvold
> Fix For: 2.12.2
>
> Attachments: ForkedBooter.patch
>
>
> Due to a bug in Swing on Windows (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7071160) the forked process may not respond to System.exit() in class ForkedBooter after excuting swing tests on windows. This leads to a hanging build, and the only way to resolve it, is to kill the hanging process.
> After all, sending Runtime.halt() will always stop the process. But since this is not a clean shutdown (e.g. shutdown-hooks not running), this should not be the default behaviour.
> As a workaround, you could start a daemon thread as a watchdog before calling System.exit().
> The deamon sleeps for a certain time, let's say a minute. If it ever resumes from sleeping, it means that the JVM is still running, so the System.exit() was not completed in that time. Now it's time to call Runtime.halt() as a last exit.
> We used this strategy to overcome the Swing bug (see attached patch).
> I guess it would be nice, if the timeout would be configurable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira