Инструменты отслеживания выполнения процесса - PullRequest
2 голосов
/ 09 октября 2009

В настоящее время я занимаюсь расследованием очень специфической проблемы на наших лабораторных серверах. Всякий раз, когда мы запускаем Java-программу на машине с 64-битной установкой SUSE SLES11, к которой обращался Citrix, она просто зависает. У меня есть последние обновления на машине, но это не помогает. Если любое из этих обстоятельств изменится, оно будет работать: 32-битная ОС, SLES10.2, доступ через Cygwin / Exceed и другие приложения X, такие как xclock, работают нормально.

Пока что это может выглядеть как вопрос ServerFault, но на самом деле я ищу предложения по программному обеспечению, которые я могу использовать для отслеживания того, что на самом деле делает это программное обеспечение. Там, где он висит, находится «FUTEX_WAIT» (определяется с помощью strace ):

futex(0x7f4e3eaab9e0, FUTEX_WAIT, 19686, NULL

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

ОБНОВЛЕНИЕ: Судя по всему, проблемы futex_wait являются признаком странных состояний гонки в процессах блокировки ядра / libc. Мне придется попробовать с более новым ядром / libc и посмотреть, если что-то из этого имеет какое-либо значение.

ОБНОВЛЕНИЕ2: изменения в ядре / libc не изменились. Удалось запустить jvisualvm и повесить его с предсказуемым внешним JMX-портом и подключить к нему с другой машины, и в этот момент я обнаружил это в трассировке потока для main:

Name: main
State: RUNNABLE
Total blocked: 0  Total waited: 0

Stack trace: 
sun.awt.X11GraphicsDevice.getDoubleBufferVisuals(Native Method)
sun.awt.X11GraphicsDevice.makeDefaultConfiguration(X11GraphicsDevice.java:208)
sun.awt.X11GraphicsDevice.getDefaultConfiguration(X11GraphicsDevice.java:182)
   - locked java.lang.Object@1c190c99
sun.awt.X11.XToolkit.<clinit>(XToolkit.java:92)
java.lang.Class.forName0(Native Method)
java.lang.Class.forName(Class.java:169)
java.awt.Toolkit$2.run(Toolkit.java:834)
java.security.AccessController.doPrivileged(Native Method)
java.awt.Toolkit.getDefaultToolkit(Toolkit.java:826)
   - locked java.lang.Class@308a1f38
org.openide.util.ImageUtilities.ensureLoaded(ImageUtilities.java:519)
org.openide.util.ImageUtilities.access$200(ImageUtilities.java:80)
org.openide.util.ImageUtilities$ToolTipImage.createNew(ImageUtilities.java:699)
org.openide.util.ImageUtilities.getIcon(ImageUtilities.java:487)
   - locked java.util.HashMap@3c07ae6d
org.openide.util.ImageUtilities.getIcon(ImageUtilities.java:361)
   - locked java.util.HashMap@1c4c94e5
org.openide.util.ImageUtilities.loadImage(ImageUtilities.java:139)
org.netbeans.core.startup.Splash.loadContent(Splash.java:262)
org.netbeans.core.startup.Splash$SplashComponent.<init>(Splash.java:344)
org.netbeans.core.startup.Splash.<init>(Splash.java:170)
org.netbeans.core.startup.Splash.getInstance(Splash.java:102)
org.netbeans.core.startup.Main.start(Main.java:301)
org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:110)
java.lang.Thread.run(Thread.java:619)

Попробовал кнопку обнаружения тупиковых ситуаций в jvisualvm, но он не обнаружил тупиковых ситуаций.

В настоящее время мы говорим с Citrix Europe об этой проблеме и предоставляем им следы. Обновит этот вопрос, если он будет решен.

ОБНОВЛЕНИЕ 3: Эта проблема была прослежена до Citrix и была отправлена ​​с номером запроса на обслуживание 60235154. Похоже, что проблема находится где-то в Java или в реализации Citrix X11 на данный момент.

Ответы [ 5 ]

2 голосов
/ 08 декабря 2009

ltrace отслеживает вызовы функций совместно используемой библиотеки. Это может дать вам более высокий уровень взгляда на вещи. Но он также может израсходовать гораздо больше выходных данных, чем strace, поскольку многие библиотечные функции (например, strcmp) не приводят к системным вызовам.

Но futex используется для блокировки, поэтому, если вы застряли в futex, вы, вероятно, зашли в тупик. Или вы просто смотрите на одну нить, которая ждет других тем. ltrace / strace -f следует за clone / fork для отслеживания всех потоков / всех дочерних процессов.

В GDB иногда thread apply all <command> полезно для многопоточных процессов. например thread apply all bt

1 голос
/ 10 декабря 2009

Может быть, jvisualvm, который поставляется с java от Sun, имеет то, что вам нужно. Вы можете записывать состояние виртуальной машины во время работы вашей программы, а также указывать ей сохранять дампы стека в файл, который вы позже сможете открыть и просмотреть. Найдите jvisualvm в каталоге bin вашего jdk. Здесь вы можете увидеть больше документации: http://java.sun.com/javase/6/docs/technotes/tools/share/jvisualvm.html

Удачи!

1 голос
/ 10 октября 2009

Есть ли у вас исходный код для программы на Java? Если это так, вы можете удаленно отладить с помощью Eclipse или другой IDE. Если у вас нет исходного кода, ваши параметры более ограничены, но вы можете попробовать подключиться к процессу через JConsole , чтобы получить представление о том, что происходит. Инструменты профилирования Java - еще один вариант, но его сложнее настроить.

0 голосов
/ 18 июня 2013

См. это решение Я нашел.

В этом случае зависания были вызваны медленной генерацией случайных байтов из /dev/random.

Приложение Java очень долго ожидает получения случайных байтов.

Это на самом деле не решение, а обходной путь, поскольку / dev / random станет таким же, как /dev/urandom.

0 голосов
/ 09 октября 2009

Используйте GDB для присоединения к процессу. GDB не совсем интуитивно понятен, но в сети много хоутов и аналогичных материалов.

http://dirac.org/linux/gdb/06-Debugging_A_Running_Process.php

...