LINUX.ORG.RU

Падает java с valgrind

 , , ,


0

3

Добрый день! Прошу подсказать в чём может быть проблема:

Создал docker-контейнер на базе Астра Линукс 1.7.4 (registry.astralinux.ru/library/alse:1.7.4)

Внутри установил AxiomJDK 11 (https://download.axiomjdk.ru/axiomjdk-pro/11.0.19+7/axiomjdk-jdk-pro11.0.19+7-linux-amd64.deb)

И valgrind (apt install valgrind)

Запускаю в контейнере команду типа такой:

valgrind --tool=memcheck --leak-check=summary --leak-resolution=low --show-leak-kinds=none --track-origins=no --log-file=valgrind.log java -jar application_name.jar

На моём компьютере и локально и в VirtualBox на виртуалке с АстраЛинукс 1.7.4 в этом docker-контейнере всё запускается(показывает много ошибок, но приложение работает). А на сервере на машине с Астра Линукс 1.7.4 в таком же контейнере jdk падает.

Получаю такое сообщение:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x000000000f953634, pid=551, tid=552
#
# JRE version: OpenJDK Runtime Environment (11.0.19+7) (build 11.0.19+7-LTS)
# Java VM: OpenJDK 64-Bit Server VM (11.0.19+7-LTS, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# v  ~StubRoutines::libmLog
#
# Core dump will be written. Default location: /opt/application_name/core
#
# An error report file with more information is saved as:
# /opt/application_name/hs_err_pid551.log
Could not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled
#
# If you would like to submit a bug report, please visit:
#   https://axiomjdk.ru/support
#
Aborted

И valgrind.log, в конце которого такие строки:

==551== Conditional jump or move depends on uninitialised value(s)
==551==    at 0x6D055FA: ImageFileReader::close(ImageFileReader*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/libjimage.so)
==551==    by 0x567593A: ClassPathImageEntry::close_jimage() (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==551==    by 0x5CD5509: os::abort(bool, void*, void const*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==551==    by 0x5FB07A6: VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==551==    by 0x5FB13CA: VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==551==    by 0x5FB13FD: VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==551==    by 0x5CE15F7: JVM_handle_linux_signal (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==551==    by 0x5CD2F47: signalHandler(int, siginfo*, void*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==551==    by 0x487872F: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.28.so)
==551==    by 0xF953633: ???
==551==    by 0xF96124A: ???
==551==    by 0xF952CC6: ???
==551==
==551==
==551== Process terminating with default action of signal 6 (SIGABRT): dumping core
==551==    at 0x4AD686B: raise (raise.c:51)
==551==    by 0x4AC1534: abort (abort.c:79)
==551==    by 0x5CD5504: os::abort(bool, void*, void const*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==551==    by 0x5FB07A6: VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==551==    by 0x5FB13CA: VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==551==    by 0x5FB13FD: VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==551==    by 0x5CE15F7: JVM_handle_linux_signal (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==551==    by 0x5CD2F47: signalHandler(int, siginfo*, void*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==551==    by 0x487872F: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.28.so)
==551==    by 0xF953633: ???
==551==    by 0xF96124A: ???
==551==    by 0xF952CC6: ???
==551==
==551== HEAP SUMMARY:
==551==     in use at exit: 58,978,591 bytes in 11,431 blocks
==551==   total heap usage: 16,413 allocs, 4,982 frees, 61,520,354 bytes allocated
==551==
==551== LEAK SUMMARY:
==551==    definitely lost: 495 bytes in 13 blocks
==551==    indirectly lost: 0 bytes in 0 blocks
==551== 	 possibly lost: 367,249 bytes in 350 blocks
==551==    still reachable: 58,610,847 bytes in 11,068 blocks
==551==		 suppressed: 0 bytes in 0 blocks
==551== Rerun with --leak-check=full to see details of leaked memory
==551==
==551== For counts of detected and suppressed errors, rerun with: -v
==551== Use --track-origins=yes to see where uninitialised values come from
==551== ERROR SUMMARY: 998565 errors from 657 contexts (suppressed: 0 from 0)

Заранее благодарен за подсказки в какую сторону копать!



Последнее исправление: enthusasist (всего исправлений: 2)

Ответ на: комментарий от enthusasist

Лики в нативных методах или в Java коде? Для второго valgrind не поможет никак. Тот что не собирает GC по меркам valgrind тем более не утечка (а на практике JVM городит свой менеджер памяти и valgrind даже отдельные объекты видеть не сможет, в лучшем случае только большие куски кучи как единое целое).

У JVM есть инструменты для дампа кучи и её анализа. Запускаешь приложение, ждёшь пока утечет много памяти, дампишь кучу, смотришь каких объектов там больше всего, затем думаешь.

KivApple ★★★★★
()
Ответ на: комментарий от alex0x08
ldd /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/libjimage.so
        linux-vdso.so.1 (0x00007fff59bd7000)
        libjvm.so => not found
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x000079e3a39fa000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000079e3a3877000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000079e3a36b7000)
        /lib64/ld-linux-x86-64.so.2 (0x000079e3a3c22000)
enthusasist
() автор топика
Ответ на: комментарий от enthusasist

Подозреваю, что без долгих и упорных настроек JVM и Valgrind ты увидишь примерно ничего. Раз на одном компьютере работает, то там и посмотри что будет в логе.

ratvier ★★
()
Ответ на: комментарий от alex0x08

При запуске с –track-origins=yes получаю:

==592== Conditional jump or move depends on uninitialised value(s)
==592==    at 0x6D055FA: ImageFileReader::close(ImageFileReader*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/libjimage.so)
==592==    by 0x567593A: ClassPathImageEntry::close_jimage() (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x5CD5509: os::abort(bool, void*, void const*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x5FB07A6: VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x5FB13CA: VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x5FB13FD: VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x5CE15F7: JVM_handle_linux_signal (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x5CD2F47: signalHandler(int, siginfo*, void*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x487872F: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.28.so)
==592==    by 0xF953633: ???
==592==    by 0xF96124A: ???
==592==    by 0xF952CC6: ???
==592==  Uninitialised value was created by a heap allocation
==592==    at 0x483577F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==592==    by 0x6D07157: operator new(unsigned long) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/libjimage.so)
==592==    by 0x6D05819: ImageFileReader::open(char const*, bool) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/libjimage.so)
==592==    by 0x567A67F: ClassLoader::create_class_path_entry(char const*, stat const*, bool, bool, Thread*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x567BA83: ClassLoader::setup_boot_search_path(char const*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x567BDE0: ClassLoader::setup_bootstrap_search_path() (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x567C474: classLoader_init1() (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x59114F8: init_globals() (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x5F434C6: Threads::create_vm(JavaVMInitArgs*, bool*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x59CF6E1: JNI_CreateJavaVM (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x488BC7E: JavaMain (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/jli/libjli.so)
==592==    by 0x48903B8: ThreadJavaMain (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/jli/libjli.so)
==592== 
==592== 
==592== Process terminating with default action of signal 6 (SIGABRT): dumping core
==592==    at 0x4AD686B: raise (raise.c:51)
==592==    by 0x4AC1534: abort (abort.c:79)
==592==    by 0x5CD5504: os::abort(bool, void*, void const*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x5FB07A6: VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x5FB13CA: VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x5FB13FD: VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x5CE15F7: JVM_handle_linux_signal (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x5CD2F47: signalHandler(int, siginfo*, void*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==592==    by 0x487872F: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.28.so)
==592==    by 0xF953633: ???
==592==    by 0xF96124A: ???
==592==    by 0xF952CC6: ???
==592== 
==592== HEAP SUMMARY:
==592==     in use at exit: 58,882,279 bytes in 11,442 blocks
==592==   total heap usage: 16,576 allocs, 5,134 frees, 62,017,224 bytes allocated
==592== 
==592== LEAK SUMMARY:
==592==    definitely lost: 527 bytes in 14 blocks
==592==    indirectly lost: 0 bytes in 0 blocks
==592==      possibly lost: 369,657 bytes in 354 blocks
==592==    still reachable: 58,512,095 bytes in 11,074 blocks
==592==         suppressed: 0 bytes in 0 blocks
==592== Rerun with --leak-check=full to see details of leaked memory
==592== 
==592== For counts of detected and suppressed errors, rerun with: -v
==592== ERROR SUMMARY: 945660 errors from 700 contexts (suppressed: 0 from 0)
enthusasist
() автор топика
Ответ на: комментарий от enthusasist

Uninitialised value was created by a heap allocation ==592== at 0x483577F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==592== by 0x6D07157: operator new(unsigned long) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/libjimage.so)

У меня два предположения: несовместимость Valgrind с конкретно этой JDK (это «васянская сборка» если что) либо headless режим.

Попробуй локально запустить с -Djava.awt.headless=true и посмотреть будет ли падение.

alex0x08 ★★★
()
Ответ на: комментарий от alex0x08

headless режим попробовал и локально и на сервере. Такая же ситуация: локально всё работает, на сервере - падает

==618== Conditional jump or move depends on uninitialised value(s)
==618==    at 0x6D055FA: ImageFileReader::close(ImageFileReader*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/libjimage.so)
==618==    by 0x567593A: ClassPathImageEntry::close_jimage() (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x5CD5509: os::abort(bool, void*, void const*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x5FB07A6: VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x5FB13CA: VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x5FB13FD: VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x5CE15F7: JVM_handle_linux_signal (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x5CD2F47: signalHandler(int, siginfo*, void*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x487872F: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.28.so)
==618==    by 0xF953633: ???
==618==    by 0xF96124A: ???
==618==    by 0xF952CC6: ???
==618==  Uninitialised value was created by a heap allocation
==618==    at 0x483577F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==618==    by 0x6D07157: operator new(unsigned long) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/libjimage.so)
==618==    by 0x6D05819: ImageFileReader::open(char const*, bool) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/libjimage.so)
==618==    by 0x567A67F: ClassLoader::create_class_path_entry(char const*, stat const*, bool, bool, Thread*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x567BA83: ClassLoader::setup_boot_search_path(char const*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x567BDE0: ClassLoader::setup_bootstrap_search_path() (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x567C474: classLoader_init1() (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x59114F8: init_globals() (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x5F434C6: Threads::create_vm(JavaVMInitArgs*, bool*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x59CF6E1: JNI_CreateJavaVM (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x488BC7E: JavaMain (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/jli/libjli.so)
==618==    by 0x48903B8: ThreadJavaMain (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/jli/libjli.so)
==618== 
==618== 
==618== Process terminating with default action of signal 6 (SIGABRT): dumping core
==618==    at 0x4AD686B: raise (raise.c:51)
==618==    by 0x4AC1534: abort (abort.c:79)
==618==    by 0x5CD5504: os::abort(bool, void*, void const*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x5FB07A6: VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x5FB13CA: VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x5FB13FD: VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x5CE15F7: JVM_handle_linux_signal (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x5CD2F47: signalHandler(int, siginfo*, void*) (in /usr/lib/jvm/axiomjdk-java11-pro-amd64/lib/server/libjvm.so)
==618==    by 0x487872F: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.28.so)
==618==    by 0xF953633: ???
==618==    by 0xF96124A: ???
==618==    by 0xF952CC6: ???
==618== 
==618== HEAP SUMMARY:
==618==     in use at exit: 58,913,616 bytes in 11,417 blocks
==618==   total heap usage: 16,502 allocs, 5,085 frees, 61,935,756 bytes allocated
==618== 
==618== LEAK SUMMARY:
==618==    definitely lost: 303 bytes in 7 blocks
==618==    indirectly lost: 0 bytes in 0 blocks
==618==      possibly lost: 324,192 bytes in 308 blocks
==618==    still reachable: 58,589,121 bytes in 11,102 blocks
==618==         suppressed: 0 bytes in 0 blocks
==618== Rerun with --leak-check=full to see details of leaked memory
==618== 
==618== For counts of detected and suppressed errors, rerun with: -v
==618== ERROR SUMMARY: 1036017 errors from 649 contexts (suppressed: 4 from 2)
enthusasist
() автор топика
Ответ на: комментарий от alex0x08

Запустил для проверки с openjdk11 вместо axiomjdk. Так же падает:

==4736== Conditional jump or move depends on uninitialised value(s)
==4736==    at 0x65353AA: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/libjimage.so)
==4736==    by 0x540F0EA: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x59F70C2: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x5C9EA4D: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x5C9F73A: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x5C9F76D: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x5A01C1D: JVM_handle_linux_signal (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x59F4537: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x487B72F: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.28.so)
==4736==    by 0xED72633: ???
==4736==    by 0xED8024A: ???
==4736==    by 0xED71CC6: ???
==4736==  Uninitialised value was created by a heap allocation
==4736==    at 0x4835DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==4736==    by 0x65355C9: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/libjimage.so)
==4736==    by 0x54136B3: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x5413F2E: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x541420C: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x5685938: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x5C3BC79: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x572FD70: JNI_CreateJavaVM (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x488E867: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/jli/libjli.so)
==4736==    by 0x48935C8: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/jli/libjli.so)
==4736==    by 0x4870FA2: start_thread (pthread_create.c:486)
==4736==    by 0x499CFEE: clone (clone.S:95)
==4736== 
==4736== 
==4736== Process terminating with default action of signal 6 (SIGABRT): dumping core
==4736==    at 0x48DB86B: raise (raise.c:51)
==4736==    by 0x48C6534: abort (abort.c:79)
==4736==    by 0x50EAFE0: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x5C9EA4D: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x5C9F73A: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x5C9F76D: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x5A01C1D: JVM_handle_linux_signal (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x59F4537: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so)
==4736==    by 0x487B72F: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.28.so)
==4736==    by 0xED72633: ???
==4736==    by 0xED8024A: ???
==4736==    by 0xED71CC6: ???
==4736== 
==4736== HEAP SUMMARY:
==4736==     in use at exit: 54,913,503 bytes in 11,437 blocks
==4736==   total heap usage: 16,459 allocs, 5,022 frees, 57,915,692 bytes allocated
==4736== 
==4736== LEAK SUMMARY:
==4736==    definitely lost: 303 bytes in 7 blocks
==4736==    indirectly lost: 0 bytes in 0 blocks
==4736==      possibly lost: 300,879 bytes in 308 blocks
==4736==    still reachable: 54,612,321 bytes in 11,122 blocks
==4736==         suppressed: 0 bytes in 0 blocks
==4736== Rerun with --leak-check=full to see details of leaked memory
==4736== 
==4736== For counts of detected and suppressed errors, rerun with: -v
==4736== ERROR SUMMARY: 1016959 errors from 724 contexts (suppressed: 0 from 0)

Т.е. похоже всё-таки проблема в чём-то на сервере. Несмотря на то, что и локально и на сервере запускаю в одинаковых docker-контейнерах.

enthusasist
() автор топика
Ответ на: комментарий от enthusasist

А нет сообщений от ООМ-киллера в journalctl -ex ?

0x4835DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)

Посмотри зависимости этой библиотеки через ld , может тоже что-то не нашлось.

alex0x08 ★★★
()

Could not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled

оно уже у тебя прямо ругается что нет этой либы. или не? хотя это либа похоже отвечает за дизассеблер при дебаге. тогда да..

VKraft ★★
()
Последнее исправление: VKraft (всего исправлений: 1)
Ответ на: комментарий от VKraft

Мне кажется это она ругается уже когда её valgrind останавливает. Пробовал запускать с параметрами:

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -jar application_name.jar

Получаю в основном логе:

ImmutableOopMap{r8=Oop r11=Oop rsi=Oop [48]=Oop rax=Oop }pc offsets: 881 
ImmutableOopMap{r8=Oop r11=Oop rsi=Oop [48]=Oop }pc offsets: 1011 
ImmutableOopMap{r8=Oop r9=Oop [48]=Oop }pc offsets: 1667 
ImmutableOopMap{r8=Oop r9=Oop [48]=Oop r11=Oop }pc offsets: 1677 1682 
ImmutableOopMap{r8=Oop r11=Oop rsi=Oop [48]=Oop }pc offsets: 1701 
ImmutableOopMap{r8=Oop r11=Oop rsi=Oop [48]=Oop rdi=Oop }pc offsets: 1706 1711 
ImmutableOopMap{r8=Oop r11=Oop rsi=Oop [48]=Oop rdi=Oop rax=Oop }pc offsets: 1725 1785 1794 
ImmutableOopMap{r8=Oop r11=Oop rsi=Oop [48]=Oop rax=Oop }pc offsets: 1876 
ImmutableOopMap{r8=Oop r11=Oop rsi=Oop [48]=Oop }pc offsets: 1909 
ImmutableOopMap{r8=Oop r9=Oop [48]=Oop }pc offsets: 2000 
ImmutableOopMap{r9=Oop [48]=Oop rsi=Oop }pc offsets: 2005 2010 2024 2085 2094 Compiled method (c1)   12332  251       3       jdk.internal.org.objectweb.asm.Item::set (219 bytes)
 total in heap  [0x0000000010156810,0x00000000101574b0] = 3232
 relocation     [0x0000000010156988,0x0000000010156a20] = 152
 main code      [0x0000000010156a20,0x0000000010157080] = 1632
 stub code      [0x0000000010157080,0x0000000010157110] = 144
 metadata       [0x0000000010157110,0x0000000010157118] = 8
 scopes data    [0x0000000010157118,0x0000000010157260] = 328
 scopes pcs     [0x0000000010157260,0x0000000010157470] = 528
 dependencies   [0x0000000010157470,0x0000000010157478] = 8
 nul chk table  [0x0000000010157478,0x00000000101574b0] = 56

ImmutableOopMap{[72]=Oop [56]=Oop [48]=Oop }pc offsets: 988 
ImmutableOopMap{[72]=Oop [56]=Oop }pc offsets: 1036 
ImmutableOopMap{[72]=Oop }pc offsets: 1084 
ImmutableOopMap{[72]=Oop [48]=Oop }pc offsets: 1164 
ImmutableOopMap{[72]=Oop }pc offsets: 1212 1300 
ImmutableOopMap{rsi=Oop [72]=Oop rcx=Oop r8=Oop [48]=Oop r9=Oop }pc offsets: 1362 
ImmutableOopMap{rcx=Oop [56]=Oop [48]=Oop [72]=Oop }pc offsets: 1537 
ImmutableOopMap{[72]=Oop [56]=Oop r8=Oop [48]=Oop }pc offsets: 1542 
ImmutableOopMap{[72]=Oop r9=Oop }pc offsets: 1547 
ImmutableOopMap{[72]=Oop [48]=Oop rcx=Oop }pc offsets: 1552 
ImmutableOopMap{[72]=Oop r8=Oop [48]=Oop }pc offsets: 1557 
ImmutableOopMap{rcx=Oop [72]=Oop }pc offsets: 1562 Compiled method (c1)   12382  258       1       java.lang.invoke.MethodType::ptypes (5 bytes)
 total in heap  [0x0000000017542d90,0x0000000017543050] = 704
 relocation     [0x0000000017542f08,0x0000000017542f28] = 32
 main code      [0x0000000017542f40,0x0000000017542fc0] = 128
 stub code      [0x0000000017542fc0,0x0000000017542ff0] = 48
 metadata       [0x0000000017542ff0,0x0000000017542ff8] = 8
 scopes data    [0x0000000017542ff8,0x0000000017543008] = 16
 scopes pcs     [0x0000000017543008,0x0000000017543048] = 64
 dependencies   [0x0000000017543048,0x0000000017543050] = 8
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x000000000f953634, pid=835, tid=836
#
# JRE version: OpenJDK Runtime Environment (11.0.19+7) (build 11.0.19+7-LTS)
# Java VM: OpenJDK 64-Bit Server VM (11.0.19+7-LTS, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# v  ~StubRoutines::libmLog
#
# Core dump will be written. Default location: /opt/application_name/core
#
# An error report file with more information is saved as:
# /opt/application_name/hs_err_pid835.log
#
# If you would like to submit a bug report, please visit:
#   https://axiomjdk.ru/support
#
enthusasist
() автор топика
Ответ на: комментарий от enthusasist

SIGILL (0x4)

дальше гугли сам. у меня времени нет. но система прибивает java процесс. или у него не хватает прав или платформа не может в набор иструкций. всё

VKraft ★★
()

Тебе же пишет

An error report file with more information is saved as: /opt/application_name/hs_err_pid551.log Could not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled

Подробная информация в этом файле. Можешь запустить jvm приложение с флагом -XX:ErrorFile=/dump/hs_err_pid%p.log и через volume пробросить директорию /dump из контейнера на хост, чтобы посмотреть лог краша. Проблема где-то с файлом hsdis-amd64.so.

И да, valgrind тебе не покажет утечки java-приложения, для этого существуют другие инструменты.

ma1uta ★★★
()
Ответ на: комментарий от alex0x08

Define «васянская сборка».

Axiomjdk - это liberica jdk (от ребят из Питера, которые при работе в Sun и Oracle написали примерно 40% всей jvm) с другим названием, это вся та же OpenJDK с прохождением TCK.

ma1uta ★★★
()
Ответ на: комментарий от ma1uta

Define «васянская сборка».

Неофициальная сборка, по прямой аналогии с левыми сборками венды.

(от ребят из Питера, которые при работе в Sun и Oracle написали примерно 40% всей jvm)

Тесты они писали, тесты. Никакая часть JDK в СНГ не разрабатывалась, никогда насколько я знаю.

с другим названием, это вся та же OpenJDK с прохождением TCK.

Не очень понимаю какой в этом смысл, OpenJDK это открытый проект поддерживаемый кучей разных вендоров, но OracleJDK все также «профессиональный», с патчами и поддержкой. Там например есть дополнительные кодеки, проприетарные.

Конечно ввиду последних событий это уже неактуально и приходится кушать что дают, но тем не менее.

alex0x08 ★★★
()
Ответ на: комментарий от alex0x08

Неофициальная сборка, по прямой аналогии с левыми сборками венды.

Тогда и adoptOpenJDK, Correto JDK, RedHat JDK и прочие.

Никакая часть JDK в СНГ не разрабатывалась, никогда насколько я знаю.

В том то и проблема, что не знаешь, а оно там было, например, вот: https://www.cnews.ru/news/top/chem_zanyat_centr_razrabotok_oracle_v_rossii

Не очень понимаю какой в этом смысл, OpenJDK это открытый проект поддерживаемый кучей разных вендоров, но OracleJDK все также «профессиональный», с патчами и поддержкой. Там например есть дополнительные кодеки, проприетарные.

Начиная с 11-ой версии неактуально: https://blogs.oracle.com/java/post/oracle-jdk-releases-for-java-11-and-later. И по факту та же LibericaJDK, AdoptOpenJDK ничем не отличается от OracleJDK, всё эти сборки такие же «профессиональные».

ma1uta ★★★
()
Ответ на: комментарий от ma1uta

В том то и проблема, что не знаешь,

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

Так что информация из первых рук.

Но вообщем-то у Оракла были еще центры и занимались там кастомизацией и локализацией корпоративного софта, вот одна из характерных вакансий тех лет.

Кастомизация, локализация и тесты производительности но никак не разработка самой JDK.

Начиная с 11-ой версии неактуально: https://blogs.oracle.com/java/post/oracle-jdk-releases-for-java-11-and-later.

Это лишь изменения в лицензионной политике и то не на все, а на часть которая и так была открыта но по старой CDDL.

И по факту та же LibericaJDK, AdoptOpenJDK ничем не отличается от OracleJDK, всё эти сборки такие же «профессиональные».

Отличаются когда доходит дело до поддержки. У Оракла она есть, хоть и платная, а все падения «открытых» JDK остаются на твоей совести.

Если упадет какой-нибудь Weblogic, где один холодный старт в пару минут - тебе голову оторвут за твой «открытый аналог» на продакшне.

alex0x08 ★★★
()
Последнее исправление: alex0x08 (всего исправлений: 1)

Заранее благодарен за подсказки в какую сторону копать!

Первым делом можно попробовать установить Джава-машину на сервере без всяких контейнеров и пересобрать из исходных текстов запускаемый файл там.

Затем запустить этот исполняемый файл в Джава-машине без контейнера на сервере.

Дальше уже ясно станет в чем причина неработоспособности приложения.

Enthusiast ★★
()
Ответ на: комментарий от alex0x08

Я про то, что поддержка от корпараса толщиной с оракла это не то, на что есть смысл тратить деньги. Понятно, что если ты другой корпорас, то нужно покупать саппорт, но это другой вопрос.

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

Я про то, что поддержка от корпараса толщиной с оракла это не то, на что есть смысл тратить деньги. Понятно, что если ты другой корпорас, то нужно покупать саппорт, но это другой вопрос.

А я про то что не стоит говорить от лица корпораций, попивая сок у себя на ЛОРе. За себя говори, проще будет.

alex0x08 ★★★
()
Ответ на: комментарий от enthusasist

Конкретно с этой ВМ проблема была в том, что на гипервизоре процессор был выставлен виртуальный KVMовский. После того, как поменяли на получение проца с хоста эта проблема исчезла. Но всё равно конечно очень много ошибок в логах. На минимальных настройках детализации приложение работает, а если сделать более детально и/или пробовать подавлять ошибки, то вешается намертво.

enthusasist
() автор топика
Ответ на: комментарий от enthusasist

И очень много ошибок типа такой:

==1== Invalid write of size 4
==1==    at 0xF960890: ???
==1==    by 0x101D2E93: ???
==1==    by 0xF95C266: ???
==1==    by 0xF95C266: ???
==1==    by 0xF95C266: ???
==1==    by 0xF95BFBF: ???
==1==    by 0xF95C266: ???
==1==    by 0xF95BFBF: ???
==1==    by 0xF95C0A1: ???
==1==    by 0xF95BFBF: ???
==1==    by 0xF95BFBF: ???
==1==    by 0xF95BFBF: ???
==1==  Address 0x68b1280 is on thread 2's stack
==1==  24576 bytes below stack pointer
enthusasist
() автор топика
Ответ на: комментарий от enthusasist

Как говорится: очень интересно, продолжайте наблюдения.

valgrind не предназначен для Java. Ну или Java не предназначена для valgrind. Поэтому процесс сей хоть и интересен, но не слишком полезен.

vbr ★★★
()
Ответ на: комментарий от vbr

Т.е. то, что они заявляют на сайте неверно? (https://valgrind.org/info/about.html)

Valgrind works with programs written in any language. Because Valgrind works directly with program binaries, it works with programs written in any programming language, be they compiled, just-in-time compiled, or interpreted. The Valgrind tools are largely aimed at programs written in C and C++, because programs written in these languages tend to have the most bugs! But it can, for example, be used to debug and profile systems written in a mixture of languages. Valgrind has been used on programs written partly or entirely in C, C++, Java, Perl, Python, assembly code, Fortran, Ada, and many others.
enthusasist
() автор топика
Ответ на: комментарий от enthusasist

The Valgrind tools are largely aimed at programs written in C and C++

Это, думаю, верно.

А про остальные - ну сам видишь. Можешь пытаться убрать false positives, но боюсь, что дело это будет долгое. valgrind работает на тех проектах, которые с самого начала на нём тестировались непрерывно.

vbr ★★★
()