Вот, дали очередное задание. Проверить запуск Swing приложения на Linux системе.
Ну, как обычно, выскакивает окно с бегущей линейкой загрузки. Поверх появляется диалоговое окно для ввода логина и пароля.
Вроде, ничего не предвещает беды. И вдруг, программа умирает и в окне терминала жалобное сообщение

Смотрю в интернете. Куча сообщений с такими ошибками и все такие древние. Ну, максимум 2011 года. А у меня за окном середина лета 2015. И система не самая древняя - Ubuntu 15.04 x64 и JDK от Oracle распоследних версий. Целый зоопарк, 1.6, 1.7 и 1.8.
И самое печальное, ошибка одна и та же для всех JDK.

Кое как вычислил, что падение идет в вызове метода removeNotify() в Component.java, вызов метода peer.dispose().

Да, у меня интегрированная intel ivy bridge и 2 монитора. Один вытянутый HD, другой кубик 19".

Есть у вас какие то соображения, как лечить эту напасть.

Blazkowicz, я оценил шутку. Спасибо.
Вы прочитали мое сообщение, или сразу в омут.
На экране появляется JDialog с двумя текстовыми полями и CheckBox, по типу, "запомнить пароль". И кнопка ввода.
Кнопка делает


Падает при отработке второго метода. Да, ходил туда отладчиком. По этой причине, нет влияние задержек на рисование в XOrg. Падение идет со 100% гарантией. Даже чинить не хочется. Мне бы так везде, 100% уверенности в работе кода

BlazkowiczА что JVM не создаёт краш дамп?
Ничего нет. Где то читал по поводу этих ошибок. Если программа не захотела сама обработать сообщение об ошибке, XOrg насильно останавливает работу программы, дабы она не испортила еще чего нибудь.

Долго изучал инструкцию Troubleshooting Guide for Java SE 6 Desktop Technologies .
2.5.2 Memory Leak Issues
-- надо поставить задержку
2.6.2 How to Troubleshoot a Crash in AWT
-- надо поставить задержку

Но как ставить задержку?
Найденный вариант решения

maytonЯ не увидел никакой шутки. Более того. Ты находишся в позиции просящего.
Тебе помогают бесплатно. Поэтому отнесись с уважением к отвечающим.
Постараюсь объяснить на пальцах.
Вот моя цитата
galsПроверить запуск Swing приложения на Linux системе.
Ну, как обычно, выскакивает окно с бегущей линейкой загрузки. Поверх появляется диалоговое окно для ввода логина и пароля.

Читаем комментарий
BlazkowiczА нет ли каких-нибудь хитрых контролов поверх JFrame? SWT? Браузера? 3D? Возможно дочерний контрол, не свинговый надо отдельно диспозить, до того как закрыть окно.

Речь идет о запуске Swing приложения. А мне сразу вопросы про SWT, браузер, 3D.



На самом деле, вся проблема в асинхронных событиях X11 и шлюза AWT X11.
В Java, все AWT события обрабатываются в потоке очереди EventQueue.
AWT Toolkit получает native сообщения в другом потоке.
Запомним, это два разных потока обработки событий. Идем дальше.
Окну, будь то JFrame или JDialog, не важно, мы даем команду убраться с экрана - setVisible(false) или hide().
Процесс идет в потоке обработки AWT событий, EventQueue. Обычно это ActionListener на кнопку окна или WindowListener на закрытие окна по крестику в заголовке окна. Пока AWT отдает набор команд в диспетчер окон X11, наш любимый поток EventQueue притормаживает. AWT Toolkit успевает накопить для нас некоторый набор AWT событий.
Теперь переходим к вызову метода dispose(). Он, точнее, doDispose(), проверяет поток, в котором был вызван данный метод. Если это не EventQueue, запускает процесс EventQueue.invokeLater. Если метод пошел в потоке EventQueue, отрабатывает данную процедуру немедленно.
X11 поступает честно, отправляя все события программе. Но ни кто не регламентировал, что события X11 будут отправлены в одном потоке. Включаем полную отладку java.util.logger на FINEST. Добавляем свои строчки записи в журнал до и после вызова функций.
Видим, что AWT Toolkit обрабатывает события по закрытию окна. Далее, в журнал идет запись о вызове dispose(). Наблюдаем получение событий от X11 по уничтожению окна. Видим наше сообщение, что метод dispose() выполнился. И вот тут то мы видим AWT сообщения от уже не существующего окна. Естественно, любой запрос параметра от AWT к X11, с целью получения информации об окне, приводят XOrg X11 в полное замешательство. И выдается заветная надпись "BadWindow".

Если убрать притормаживание потока EventQueue, диспетчер AWT Toolkit не успеет разобрать все события от X11 по закрытию окна. В результате мы получим ту же картину, как прямой вызов метода dispose(). Притормаживая процесс EventQueue, мы даем диспетчеру AWT Toolkit время на обработку событий от X11. Он же, на правах хозяина, заставляет процесс EventQueue выйти из ожидания. По этой причине, мы выходим из задержки не по времени, а по исключению. Цель достигнута - AWT Toolkit успел обработать все события от X11 и может спокойно уничтожать ресурс в X11.

0FD, я уже пробовал это делать. Этот вариант не проходит. Картина та же самая. Диспетчер AWT Toolkit не успевает обработать все события скрытия окна от X11. Быстрее отрабатывает метод dispose(). Программа уходит очень далеко вперед от точки вызова метода dispose().
Скажу честно, ваш вариант работает частично. Мне не ясно, почему JOptionPane не падает. Там реализовано так, как вы предлагаете.

Но как быть с JFrame?
JFrame - это первое окно с сообщениями о загрузке приложения и бегущей линейкой. Оно точно так же, периодически, приводит к падению системы с ошибкой "BadWindow".
Я пробовал отказаться от setVisible(false). Дело в том, что метод doDispose() вызывает еще раз метод hide().
Оставлял только вызов метода dispose() по нажатию на кнопки. Для диалогового окна ставил setDefaultCloseOperation(DISPOSE_ON_CLOSE).
Всё равно, система работает не стабильно.

Я постарался везде заменить уничтожение окон на вызов метода closeAndDispose. Система работает, пока не споткнется на очередном JDialog или JFrame, до которого у меня не дошли руки. Это как-то очень печально. Программа не маленькая и писалась не один год.