JVM

падает

Ещё удивляется...

bt full

Более подробно:

(gdb) bt full
#0  0x00007fab80d260d5 in sigandset (dest=0x26c3, left=0x26d3, right=0x6) at sigandset.c:37
        __cnt = 12
#1  0x00007fab80d2983b in qsort_r (b=0x26c3, n=9939, s=6, cmp=0xffffffffffffffff, arg=0xa) at msort.c:167
        size = 0
        tmp = 0x0
        p = {s = 0, var = 0, cmp = 0, arg = 0x0, t = 0x0}
#2  0x00007fab806569c8 in WatcherThread::run (this=0x7fab78168000) at /build/buildd/openjdk-6-6b24-1.11.1/build/openjdk/hotspot/src/share/vm/runtime/thread.cpp:1184
        err = {<outputStream> = {<ResourceObj> = {<No data fields>}, _vptr.outputStream = 0x7fab80a84f70, _indentation = 0, _width = 80, _position = 0, _newlines = 1, 
            _precount = 30, _stamp = {_counter = 0}}, _fd = 1, _need_close = false}
        time_to_wait = <optimized out>
#3  0x00007fab8055ccb2 in java_start (thread=0x7fab78168000) at /build/buildd/openjdk-6-6b24-1.11.1/build/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:856
        counter = 43348
        pid = <optimized out>
        osthread = 0x7fab78168f90
        sync = 0x7fab78169070
#4  0x00007fab814bee9a in start_thread (arg=0x7fab7c6c1700) at pthread_create.c:308
        __res = <optimized out>
        pd = 0x7fab7c6c1700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -5057929828844747674, 140374589729664, 140374503594432, 0, 3, 5086929331494274150, 5087269919160747110}, 
              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = 0
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#5  0x00007fab80de338d in unshare () at ../sysdeps/unix/syscall-template.S:84
No locals.
#6  0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) 

А чего-нибудь свежее ископаемого 1.6.0_24 нету? Да, в 1.6.0_24 было полно подобных багов.

Попробуй JVM, написанную на нормальном языке программирования (Java), а не на C++.

Она падать не будет.

https://en.wikipedia.org/wiki/Maxine_Virtual_Machine

Скорее всего баг в JVM. Попробуй Oracle JVM 8.

Наступил на мозоль

Сам плююсь и ругаюсь, но ничего поделать с этим не могу.

написанную на нормальном языке программирования (Java), а не на C++.
Она падать не будет.

Ты про аббревиатуру NPE слышал чего-нибудь?

Что, даже update 45 вместо 24 невозможно накатить?

Мне сказали, что они заморозили версию Java, но никто уже не помнит почему. Буду разбираться, возможно 45 можно накатить.

аббревиатуру NPE

Первая ссылка в гугле — Norton Power Eraser.

И только косвенно, по картинкам в статье на хабре, можно предположить, что это NullPointerException. Мне даже интересно, это то самое значение, которое ты имел в виду?

А запускаешь то что под java? hello world или что посложнее?

Там крутится liferay в tomcat'е.

Первая ссылка в гугле — Norton Power Eraser.

Потому что нужно было искать вместе с Java.

клоуны слышат только звонок для выхода на арену

Стоит попробовать обновить. Возможно, всплывут другие баги (из-за которых и заморозили) - но может, их решить будет проще? Всё-таки JVM падает не каждый день.

К падению такого рода не может приводить нехватка ресурсов (памяти/потоков/whateverelse)?

Больше похоже на какой-то дикий баг в JVM. Вряд ли...

А почему не glibc? Он тоже старенький, и стектрейс вроде туда ведет

Да, может и так быть... Или несовместимость версий glibc и jre. Незадокументированная, естественно.

В чем может быть проблема?

в этом:

java version "1.6.0_24"

и в этом(возможно):

OpenJDK Runtime Environment

Мельком глянул исходники глибца, странная штука: в дампе

qsort_r (b=0x26c3, n=9939, s=6, cmp=0xffffffffffffffff, arg=0xa)
size = 0

size_t size = n*s = 9939*6 = 0?

После установки size, tmp и p дальше там идут аллокации, может на них и валится, sigabrt как раз malloc любит кидать, если не ошибаюсь. Дальше искать сложно, очень много макроподстановок.

Хотя у меня было один раз, что стектрейс показывает на место, к реальной ошибке мало оносящееся, просто такой афтерэффект.

6u24 это даже не некрофилия, это палеонтология. Советую взять восьмёрку, или последний билд шестёрки.

В чем может быть проблема?

«1.6.0_24»

В этом. OpenJDK 7 давно вышел.

Черт возьми! Я думаю ты просто гений!

Было бы здорово, если бы тому существовало какое-либо доказательство. Bug в багзилле openjdk или libc вполне подошел бы. Я пока ничего похожего найти не смог. Возможно, плохо искал.

Ты не выхлоп gdb кидай нам, а содержимое файла hs_err_pid*.log, в котором причина смерти JVM более-менее подробнее описана быть должна.

Там как минимум стектрейс кода, который JVM в момент смерти выполняло (а не стектрейс самой JVM, который тебе не сильно поможет) плюс список тредов, которые JVM выполняла в момент контузии.

Нету hs_err_pid файла. JVM его по каким-то причинам не пишет. Такое бывает.