При запуске приложения сделать new получается нормально, и если приложение поработало около 12 часов, то потом когда этот класс пытаюсь создать - бросается исключение вот такое:

ява-машинаException in thread "Thread-11" java.lang.NoClassDefFoundError: console/Command
at console.ConsoleServer$Console.run(ConsoleServer.java:188)
Caused by: java.lang.ClassNotFoundException: console.Command
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)


(в нем console- мой пакет, ConsoleServer-мой класс, в котором делается new Command(...) )

Файл Command.class есть в составе jar-файла. Проект создавался в нетбинсе, настройки - стандартные...
Если бы этого класса не было, то проект даже не откомпилился бы. jar-файл после компиляции никаким изменениям не подвергался classpath на этапе выполнения тоже не меняю, из сторонних либ только ini4j, которая дергается только в момент запуска.

В чем может быть дело?


Manifest.mf выглядит так:

netbeansManifest-Version: 1.0
Ant-Version: Apache Ant 1.8.2
Created-By: 1.6.0_29-b11 (Sun Microsystems Inc.)
Class-Path:
X-COMMENT: Main-Class will be added automatically by build
Main-Class: MyApp.Main


Он был создан не руками, а кнопочкой "build" в нетбинсе... Всякие файлы заданий для ant - тоже стандартные, созданные нетбинсом по умолчанию. Приложение простое консольное.

авторЧто именно у вас отработало 12 часов?
Мое приложение

И что именно вы делаете когда возникает ошибка. Делаете new в проекте, который отработал 12 часов?

Весь код приводить - слишком много кода.
скажем так - к серверсокету, открытому приложением 12 часов, не было входящих подключений. То есть поток висел 12 часов на socket.accept();

Потом я конекчусь на него, хоть даже телнетом (в приложении создается поток-обработчик соединения), и закидываю ему данные. (набираю в телнете блаблабла и жму энтер)

Обработчик соединения видит - ему пришли данные и "\r", значит надо их обработать. Делает new Command(data);
Для данного примера data у меня равно "блаблабла\r". Command - это мой класс, принимающий строку в конструкторе.

И этот new Command(data); выбрасывает исключение


авторПроект отработал, или приложение в JMV?
эээ...а в чем отличие? и что такое JMV?

У меня простое консольное приложение, созданное в нетбинсе, со стандартными настройками. Сделал Build - получил MyApp.jar
и запускаю:
> java -jar MyApp.jar &>mylog.log &
проходит ~12 часов
и происходит то, что я написал выше. Если коннектиться телнетом раньше, то все ок. Такое впечатление, что баг возникает nj kb если socket.accept() ждет долгое время, то ли когда приложение долго работает. Все эти 12 часов в других потоках что-то крутилось, создавалось, и много чего делалось, но new Command() нигде не делалось. То есть такое впечатление, что gc очистил "лишние" классы и под его горячую руку попали те, что долго не были нужны.


авторЧто значит "отработало 12 часов"? где запущено приложение - в консоли, апп сервере или еще как? И поясните, как вы "создаете" класс?

Даа, вот то и значит. Запустили, проверили - все ок, все работает. Легли спать. Утром просыпаемся, конектимся - выкидывает ошибку. Перезапустили. Проверили - все ок. Вечером конектимся - снова ошибка.

Приложение запущено в консоле.
"создаю" инстанс класса посредством оператора new, всякую там рефлексию не использую - не нужна. жава машину использую шестую.

авторЭто полный stacktrace?
скопипастил все информативное, что вывелось, там еще "... 1 more"

Сегодня утром баг воспроизвести не получилось. Теперь ждем до вечера :./

Что я сделал вчера
1. мне показалось, что имена классов слишком "стандартны" и я их переименовал на всякий случай. Чтобы они не пересеклись с какими-нибудь системными. Глупо конечно, но тем не менее.
2. добавил try-cacth, с рапечаткой полного стактрейса
3. добавил в командную строку <&- Этот финт ушами, согласно статье на хабре, закрывает поток ввода. Согласно статье, надо делать еще и System.in.close(). Но у меня одновременно <&- в строке запуска и close() в программе не заработало - ругалось на класслодеры еще при загрузке. То есть либо одно, либо другое.

А чем странный стактрейс? Может это в jre новой он такой и есть? Потому что все мои действия сейчас направлены в большей степени на получение полного стактрейса, поэтому рекомендации, которые мне тут дали, я пока не начал пробовать.

насколько я нагуглил, NoClassDefFoundError возникает, когда на этапе исполнения jvm не может найти класс. Получается, что этот баг может возникать по вине операционки, или если jar-ник за эти ~12 часов подменили? У меня его никто не подменял, но может операционка (убунту 10.10) решила, что его заменили, или "не увидела" его по какой-нибудь другой причине?

Мог ли баг возникнуть от того, что PATH не была установлена в $JAVA_HOME/bin:$JAVA_HOME/lib hotspot jvm, а в том PATH, который был в системе, была openjdk? (если что - под openjdk оно тоже глючило, но или вообще тихо или с падением по sigbus где-то внутри libz, потому и решил потестить на hotspot)

возможно, я выяснил причину

У меня скрипт, который по крону перезапускал приложение, делал export JAVA_HOME=путь, а только потом порверял есть ли это приложение в списке процессов. То есть получается, JAVA_HOME ставилось раз в 5 минут. И хоть оно ставилось таким же точно, это, теоретически, могло плохо повлиять на работу jvm.

сейчас я подкрректировал и это. Посмотрим, что будет.

Правда. Ну может не 12, может 7..8. Но это ничего не меняет по сути.
Логи не врут. Каждый акт перезапуска - это запись в лог.

Перезапуск был сделан скорей на всякий случай, если выключат/перегрузят машину, а так вообще приложение не падало.
Кстати, мягких и софт-ссылок тоже не использую.

Да, и 7..8ч - это не в том смысле, что оно упало через 7 часов, а в том смысле, что вышеописанный баг был зафиксирован через это время. Ну то есть где-то в 12 ночи запустил, проверил все - рабоатет. А в 9-10утра снова проверил и - уже в логах экзепшен.

То есть идея в том, что баг появляется через довольно большое время.

...

Так а что не так в стактрейсе? Почему он у вас вызывает подозрения? Потому, что там Unknown Source? ну так я запускал под jre, а не под jdk - возможно, поэтому.

Шестерка. Пользую 1.6.0_30

Сегодня опять баг вылез. И опять полный стактрейс не распечало. printStackTrace() пишет " ...1 more", а попытка сделать for(StackTraceElement ste:ex.getStackTrace())System.out.println(ste.toString()); тоже не увенчалась успехом - вообще отдало одну последнюю строчку :(

Добавил по совету -Xnoclassgc и проверку доступности ресурса. Запустил - пробую приконнектится - jvm падает c SIGSEGV. Создается лог со всякими регистрами, потоками и тд и тп. Создается коредамп java-машины. Падает где-то внутри libc.so. Не знаю, уместно ли сюда давать 20кб логов. По этим логам памяти машине вроде хватает. В свопе системы вообще 0. Памяти внути жава-машины тоже хватает.

Запускаю второй раз - все работает. Посмотрим. Вообще никаких идей. Падение жава-машины настораживает. Дело в том, что этот поток вообще самый простой и независимый. Он никуда в другие потоки не лезет, и с другими потоками не контактирует, фактически.

Добавлю
Я бы подозревал аппаратную ошибку, но до этого я пробовал openJDK. Данный поток под ней тоже был проблемный, что и сподвигло меня пробовать другую jvm. Если бы это было аппаратное, то вряд ли вылет был бы в том же потоке с похожими симптомами и много раз. И комп вроде не глючный.

Пожалуюй, сие может иметь отношение к багу:

К машине подключен утеловский 3g-модем. Этот модем периодически может переконнекчиваться, при этом айпи-адрес машине может выдаваться с другой. А сокет открыт на прослушку соединений с 0.0.0.0
ну и еще dyndns юзаю, но эот уже вряд ли имеет отношение к багу.

гипотеза такая: во время подвисшей фазы accept() в ожидании соединений, DHCP выдает машине новый айпишник.

Сейчас буду пытаться воспроизвести такую ситуацию.

Нет, не оно. Падения не случилось и все отработало нормально.