РЕДАКТИРОВАТЬ : Этот воспроизводимый SIGSEGV происходит на машине Linux с более чем одной процедурой и более 2 ГБ памяти, поэтому Java по умолчанию работает в режиме -server. Интересно, что если я заставлю «-клиента» больше не произойти сбой ... (Я все еще не совсем уверен, что делать с моим воспроизводимым SIGSEGV, но, тем не менее, это интересно).
Прежде всего обратите внимание, что это немного связано, но не идентично следующему, потому что в нашем случае происходит только SIGSEGV, и мы можем надежно запустить его:
Ошибка JVM OutOfMemory «спираль смерти» (не утечка памяти)
Это связано с тем, что это происходит, когда мы наполняем наше приложение «потоком данных»: данные поступают из текстовых файлов, а затем обрабатываются по номерам (да, финансовые цифры в Java).
Я могу надежно запустить JVM для SIGSEGV, используя только действительный код Java.
ПРИМЕЧАНИЕ : я могу неизменно вызывать сбой как JVM 1.6.0_17, так и JVM 1.6.0_18, и этот вопрос не о том, как обойти эту проблему (например, при игре с параметрами VM может исправить проблему, но я не после этого, я хочу знать, что делать с этим всегда воспроизводимым SIGSEGV).
У меня есть обходной путь, который просто заключается в использовании Java 1.5 при запуске нашего приложения (хотя все еще использую Java 1.6 для одновременного запуска IntelliJ IDEA и т. Д. На одной и той же машине), но мой вопрос заключается в том, следует ли об этом сообщать или нет, и, если нужно, как сообщить об этом, зная, что сам журнал содержит конфиденциальную информацию (полный журнал hs_err _..._).
Аппаратная ошибка может быть исключена для:
это происходит на рабочей станции, которая регулярно достигает месяцев безотказной работы (я перезагружаю ее только тогда, когда выпускаются критические исправления безопасности, затрагивающие мой урезанный и усиленный Debian Linux, что на самом деле не часто), и на каких приложениях никогда не вылетает (очень маловероятно, что это аппаратная проблема на этом компьютере [подробнее ниже])
одно и то же приложение отлично работает на той же машине под JVM 1.5 под той же нагрузкой (вот как я тестирую приложение: я просто запускаю его под 1,5 ВМ)
одно и то же приложение прекрасно работает на более чем сотне клиентских компьютеров при одной и той же (гигантской) нагрузке (ни разу не падал в Windows + JVM 1.5 или 1.6 и ни разу не падал в OS X + JVM 1.5 или 1.6 [a сбой будет означать мгновенный звонок от клиента])
другие приложения на той же машине и той же JVM 1.6.0_17 или 1.6.0_18 никогда не аварийно завершаются (например, у меня есть два экземпляра IntelliJ IDEA, работающих как два разных пользователя на той же машине, и они не авария)
машина тестируется с помощью memtest "регулярно" (перед установкой новой ОС, что произошло в последний раз, когда я установил Debian Lenny, не так давно)
Вот воспроизводимый по запросу SIGSEGV:
... $uname -a
Linux saturn 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 GNU/Linux
... $ export /home/wizard/jdk1.6.0_17/bin:$PATH
... $ java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
Запустите приложение, подайте в него «поток данных», подождите несколько секунд ...
Тогда, неизменно, для 1.6.0_17:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb76d0080, pid=30793, tid=2514328464
#
# JRE version: 6.0_17-b04
# Java VM: Java HotSpot(TM) Server VM (14.3-b01 mixed mode linux-x86 )
# Problematic frame:
# V [libjvm.so+0x4bc080]
#
# An error report file with more information is saved as:
# /home/wizard/hs_err_pid30793.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
(обратите внимание, что строка '[libjvm.so + 0x4bc080]' соответствует 1.6.0_17 для каждого SIGSEGV)
или для 1.6.0_18:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb77468f0, pid=722, tid=2514516880
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) Server VM (16.0-b13 mixed mode linux-x86 )
# Problematic frame:
# V [libjvm.so+0x4d88f0]
#
# An error report file with more information is saved as:
# /home/wizard/hs_err_pid722.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted
(обратите внимание, что строка "[libjvm.so + 0x4d88f0]" соответствует 1.6.0_18 для каждого SIGSEGV)
Проблема в том, что файл журнала содержит конфиденциальную информацию
этим нельзя поделиться.
Воспроизведение «крошечного контрольного примера», воспроизводящего проблему, также нереалистично: оно похоже на проблему, о которой говорилось выше, это происходит только тогда, когда в приложение подается «поток данных».
Обратите внимание, что одно и то же приложение, на том же оборудовании, с точно такой же JVM, но другой версией Linux (у меня был Debian Etch ранее), НЕ запускало этот SIGSEGV один раз.
Но это не означает, что JVM не виновата: это все еще может быть проблемой JVM.
Должен ли я сообщить об этом и как? (помните, что написание «воспроизводимого крошечного контрольного примера» является бредовым и что журнал содержит конфиденциальную информацию, которая не должна быть пропущена). Должен ли я просто отредактировать журнал и отправить его?
Какова процедура сообщения о таком воспроизводимом SIGSEGV, когда ваш журнал содержит конфиденциальную информацию и когда контрольный пример, воспроизводящий проблему, неосуществим?
Кто-нибудь из вас успешно открыл такую ошибку и затем увидел, что она исправлена в следующем выпуске Java?
Как вы думаете, это хорошо "для сообщества Java" сообщать о такой проблеме, или я просто не должен беспокоиться, потому что это не важно?