Ошибка Java: java.lang. IllegalArgumentException: Сигнал уже используется VM: INT
Вы должны действительно проверить журнал. Кажется, что несколько компонентов могут привести к сбою установки установщика Windows SDK с этим бесполезным сообщением об ошибке. Например, это может быть распространяемый пакет Visual C ++, как упоминалось в .
6 ответов
Это вполне может быть проблемой, связанной с реализацией JVM. Мы используем недокументированный / неподдерживаемый API ( sun.misc.Signal / SignalHandler ), и поэтому договор о поведении API не гарантируется.
Реализация IBM JVM может выполнять функции, связанные с обработкой сигналов -things отличается от реализации JVM SUN и, таким образом, вызывает эту проблему. Чтобы этот конкретный вариант использования работал в JVM SUN, но не в JVM IBM.
Но попробуйте следующее (я не могу попробовать это сам):
Выполните все комбинации при запуске JVM с одним / два / три из этих параметров и возможные комбинации значений.
- параметр
-Xrsуказывает / не указывает - свойство
ibm.signalhandling. sigintустановлен наtrue/false - свойство
ibm.signalhandling.rsустановлено наtrue/false
] (Свойства, найденные через Google в нескольких дампах ошибок, но я не могу найти по ним какой-либо конкретной документации)
Я не знаю, поддерживает ли IBM JVM также этот специальный флаг, но вы также можете попробовать добавить его, что в SUN JVM, кажется, специфичен для некоторых проблем с обработчиками сигналов в linux / solaris
-XX:-AllowUserSignalHandlers
Или попробуйте использовать собственный обработчик сигналов, если это для вас вариант. Ознакомьтесь с представленными примерами кода:
- в ссылке ниже
- Обнаружение SIGINT в приложении Java под UNIX
- Проверка обработки сигналов, собственная передача сигналов
- JDK 6 HotSpot VM - Обработка сигналов в Solaris ОС и Linux
Хотя это не так. Относится к вашей конкретной проблеме, статья IBM об обработке сигналов JVM (немного устарела, но все же в основном верна). С примерами для обработчиков сигналов в собственном коде:
Откровения по обработке и завершению сигналов Java
Но я думаю, все это может быть бесполезным, поскольку реализация IBM JVM может полагаться на обработку SIGINT для своей работы правильно и, таким образом, никогда не даст вам возможности самостоятельно обработать SIGINT .
Btw. от описания до флага -Xrs Я понимаю, что это может помешать вам делать то, что вы хотите. Он говорит
Когда
-Xrsиспользуется в JVM Sun,Откровения по обработке и завершению сигналов Java
Но я полагаю, что все это может оказаться бесполезным, поскольку реализация IBM JVM может полагаться на правильную работу самой обработки
SIGINTи, таким образом, никогда не дать вам шанса обрабатыватьSIGINTсамостоятельно.Между прочим. от описания до флага
-XrsЯ понимаю, что это может помешать вам делать то, что вы хотите. Он говоритКогда
-Xrsиспользуется в JVM Sun,Откровения по обработке и завершению сигналов Java
Но я полагаю, что все это может оказаться бесполезным, поскольку реализация IBM JVM может полагаться на правильную работу самой обработки
SIGINTи, таким образом, никогда не дать вам шанса обрабатыватьSIGINTсамостоятельно.Между прочим. от описания до флага
-XrsЯ понимаю, что это может помешать вам делать то, что вы хотите. Он говоритКогда
-Xrsиспользуется в JVM Sun, от описания до флага-XrsЯ понимаю, что это может помешать вам делать то, что вы хотите. Он говоритКогда
-Xrsиспользуется в JVM Sun, от описания до флага-XrsЯ понимаю, что это может помешать вам делать то, что вы хотите. Он говоритКогда
-Xrsиспользуется в JVM Sun, сигнальные маски для SIGINT, SIGTERM, SIGHUP и SIGQUIT не изменяются JVM и обработчики сигналов для этих сигналов не установлены .Или это может означать, что не выполняются только действия JVM по умолчанию для сигналов. Или это может зависеть от реализации JVM, что на самом деле имеется в виду.
The exception occurs because the VM already has a signal handler put in place for SIGINT. What you can/should do about this depends upon the context in which this exception is thrown.
Try starting the JVM with an -Xrs option which is valid on the IBM JVM according to this anyway. That might prevent the conflict.
EDIT: In response to your underlying desire, look at:
Runtime.getRuntime().addShutdownHook(Thread)
You subclass a thread object, and it will start as part of the shutdown (take out that -Xrs for this to work well). Some things (like calling halt on Runtime) can stop that from happening, so you do need to be aware of the possibility that it just won't end up happening.
Как написано Хайнцем Кабуцем , сигналы, которые вы можете уловить, зависят от операционная система, в которой вы работаете, и, возможно, версия JVM. Если определенная комбинация os / jvm не позволяет вам зарегистрировать сигнал, вам не повезло. Возможно, поможет настройка параметров os / vm.
Согласно вашему комментарию, добавление ловушки выключения , предложенной Ишаем, должно помочь.
Я пробовал тот же код, и он у меня работает. Думаю, в настройке может быть какая-то разница.
После добавления
System.out.println("Hello");
к сообщению дескриптора я могу запустить класс следующим образом:
z@zolty:/tmp/so$ java SignalTest & sleep 1s && kill -2 $!
[1] 20467
z@zolty:/tmp/so$ Hello
z@zolty:/tmp/so$
z@zolty:/tmp/so$ java SignalTest
[1]+ Done java SignalTest
I got this to work by using a different JVM implementation (SuSE) instead of IBM. When dealing with undocumented features, it appears that JVMs are not very consistent in behaviour.