Java VM: восстанавливаемый SIGSEGV и на 1.6.0_17 и на 1.6.0_18, как сообщить?

Править: Этот восстанавливаемый SIGSEGV происходит на машине Linux больше чем с одним proc и больше чем 2 ГБ мадам, таким образом, Java принимает значение по умолчанию к - режим сервера. Интересно достаточно, если я вызываю "-клиент" больше нет никакого катастрофического отказа... (Я все еще не слишком уверен, что сделать с моим восстанавливаемым SIGSEGV, но это интересно, тем не менее).

Сначала обратите внимание, что это немного связано, но не идентичное следующему, потому что в нашем случае это - только SIGSEGV, который происходит, и мы можем надежно инициировать его:

Ошибка JVM OutOfMemory "смертельная спираль" (не утечка памяти)

Это связано, потому что это происходит, когда мы подаем наше приложение с "наводнением данных": данные прибывают из текстовых файлов и затем уплотненные числом (да, финансовое перемалывание чисел в Java).

Я могу надежно инициировать JVM к использованию SIGSEGV только действительного кода Java.

Примечание: Я могу неизменно разрушить и JVM 1.6.0_17 adn, JVM 1.6.0_18 и этот вопрос не о том, как к обходному решению эта проблема (например, играющий с параметрами VM может устранить проблему, но я не после этого, я хочу знать, что сделать с этим всегда-reproducable SIGSEGV).

У меня есть обходное решение, которое просто состоит в использовании Java 1.5 при запуске нашего приложения (при тихом использовании Java 1.6 для выполнения ИДЕИ IntelliJ, и т.д. на той же машине, одновременно), но мой вопрос состоит в том, если об этом нужно сообщить или не и, если это должно, как сообщить об этом, зная, что сам журнал содержит конфиденциальную информацию (полный hs_err_... _log).

Аппаратная ошибка может быть исключена для:

• это происходит на рабочей станции, которая регулярно достигает месяцев времени работы (я только перезагружаю ее, когда критические патчи безопасности, влияющие на мой обрезанный вниз и укрепленный Linux Debian, выпущены, которого действительно часто не происходит), и на котором никогда не отказывают приложения (создание его очень вряд ли, что это - аппаратная проблема на той машине [больше ниже]),

• то же приложение работает отлично над той же самой машиной под JVM 1.5 при той же загрузке (это - то, как я тестирую приложение: Я просто запускаю его под 1.5 VM),

• те же работы приложения, превосходные больше чем на одной сотне клиентских машин при той же (гигантской) загрузке (никогда не отказывал однажды в Windows + JVM 1.5 или 1.6 и никогда не отказывал однажды на OS X + JVM 1.5 или 1.6 [катастрофический отказ, будут означать мгновенный телефонный вызов от клиента]),

• другое приложение на той же самой машине и том же 1.6.0_17 или 1.6.0_18 JVM никогда не отказывает (например, у меня есть два экземпляра ИДЕИ IntelliJ, работающей как два различных пользователя на той же самой машине, и они не отказывают),

• машина тестируется с 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),

Проблема состоит в том, что файл журнала содержит конфиденциальную информацию, которой нельзя поделиться.

Репродуцирование "крошечного тестового сценария", которые воспроизводят проблему, не реалистично также: это подобно проблеме, связанной выше, это только происходит, когда "наводнение данных" является feeded к приложению.

Обратите внимание, что то же самое приложение, на точно тех же аппаратных средствах, с точно той же JVM, но другая версия Linux (у меня было Травление Debian ранее) НЕ инициировала это SIGSEGV однажды.

Но это не означает, что JVM не виновным: это могла все еще быть проблема JVM.

Я должен сообщить об этом и как? (учет того факта, что запись "восстанавливаемого крошечного тестового сценария" является бредовой и что журнал содержит конфиденциальную информацию, которая не должна быть пропущена). Я должен просто отредактировать журнал и отправить его?

Что процедура должна сообщить о таком восстанавливаемом SIGSEGV, когда Ваш журнал содержит конфиденциальную информацию и когда тестовый сценарий, воспроизводящий проблему, не является реалистично выполнимым?

Какой-либо из Вас имел успех, открывающий такую ошибку, и затем видел, что это решило в последующем выпуске Java?

Вы думаете, что для сообщества Java" хорошо "сообщить о такой проблеме, или я просто не должен беспокоиться, потому что это не важно?