jstack не работает на сервере

Мы используем jstack на серверах, чтобы определить, блокируются ли Java-приложения. Он не работает на одном из наших серверов Linux. Я думаю, что версия O / S:

$cat /etc/issue.net
Red Hat Enterprise Linux Server release 5.6 (Tikanga)
Kernel \r on an \m

Версия Java, работающая на сервере:

java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)

Когда я пытаюсь:

jstack 19114

Я получил:

19114: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding

Когда я пытаюсь:

jstack -F 19114

Я получил:

Attaching to process ID 19114, please wait...
Debugger attached successfully.

Deadlock Detection:

No deadlocks found.

Thread 19180: (state = BLOCKED)
Error occurred during stack walking:
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(LinuxDebuggerLocal.java:152)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebuggerLocal.java:466)
        at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:65)
        at sun.jvm.hotspot.runtime.linux_amd64.LinuxAMD64JavaThreadPDAccess.getCurrentFrameGuess(LinuxAMD64JavaThreadPDAccess.java:92)
        at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:256)
        at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:218)
        at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:76)
        at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
        at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
        at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
        at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at sun.tools.jstack.JStack.runJStackTool(JStack.java:118)
        at sun.tools.jstack.JStack.main(JStack.java:84)
Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet0(Native Method)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$800(LinuxDebuggerLocal.java:51)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1GetThreadIntegerRegisterSetTask.doit(LinuxDebuggerLocal.java:460)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(LinuxDebuggerLocal.java:127)

Кто-нибудь знает, что вызывает это?


java jstack
person Sam Goldberg    schedule 16.11.2011    source источник

Ответы (4)


arrow_upward
18
arrow_downward

Необходимо запустить jstack от имени того же пользователя, который запустил java-процесс. Это устраняет указанную выше ошибку трассировки стека. См. эту публикацию: ошибка дампа потока jstack: ошибка get_thread_regs для lwp для получения дополнительной информации. деталь. Как только я выполнил команду jstack, ошибка исчезла.

person Sam Goldberg    schedule 20.02.2012

arrow_upward
4
arrow_downward

Синтаксис прост:

sudo -u USERID jstack PID

Пример:

sudo -u tomcat7 jstack 2498
person Suresh    schedule 20.05.2017
comment
Да, теперь я использую этот синтаксис все время. - person Sam Goldberg; 22.05.2017

arrow_upward
2
arrow_downward

Попробуйте вместо этого использовать kill -3 <pid>, чтобы получить трассировку стека вашей виртуальной машины.

person Emmanuel Bourg    schedule 16.11.2011
comment
Мы делаем это, если хотим получить дамп ванильного потока. Однако jstack анализирует дамп потока, чтобы выяснить, есть ли взаимоблокировки. Вы можете увидеть взаимоблокировки из ванильного дампа потоков, но если у вас много потоков, найти проблему намного сложнее. Jstack намного быстрее. - person Sam Goldberg; 16.11.2011
comment
Я понимаю вашу точку зрения, мое предложение - это последнее средство, это лучше, чем быть полностью слепым без результата от jstack. - person Emmanuel Bourg; 16.11.2011
comment
Спасибо, Эммануэль. Существует хороший инструмент с графическим интерфейсом от IBM, public .dhe.ibm.com/software/websphere/appserv/support/tools/jca/, который проанализирует дамп потока и определит взаимоблокировки и другие характеристики потока. Мы использовали этот подход вчера, когда не смогли заставить jstack работать. Еще раз спасибо за предложение. - person Sam Goldberg; 16.11.2011
comment
Я думаю, специфичный для Linux. но все хорошие приложения не должны быть на win, да? :) - person tgkprog; 11.03.2013

arrow_upward
2
arrow_downward

Вместо этого можно использовать jsp, который дает аналогичный результат.

Следующий jsp выводит информацию о стеке потоков на экран, но вы также можете изменить вывод в файл или использовать в обычном классе POJO.

<%@ page import="java.util.*" %><%
    Map<Thread,StackTraceElement[]> map = Thread.getAllStackTraces();
    Set tt = map.keySet();
    Iterator<Thread> ti = tt.iterator();
    Thread thrd = null;
    final String br = "<" + "br" + ">";//website does not parse it
    try{
        
        int cnt = 1;
        StackTraceElement[] st = null;
        while(ti.hasNext() ){
            thrd = ti.next();
            out.print(br + "<" + "hr" + ">" + br + cnt + " \"" + thrd.getName());
            out.println("\", priority :" + thrd.getPriority()  + ", state :" + thrd.getState());
            
            out.print(", id :" + thrd.getId() + ", hex :" +  Long.toHexString(thrd.getId()) );
            out.print(" alive :"  + thrd.isAlive() + ", daemon :" + thrd.isDaemon() );
            out.print(" interrupted  :"  + thrd.isInterrupted() + ", daemon :" + thrd.isDaemon() );
            out.print(".\n" + br);
            st = thrd.getStackTrace();
            for(int sti = 0; sti < st.length; sti++){
                out.println(br + " &nbsp; &nbsp; " + st[sti].getClassName() + "." + st[sti].getMethodName());
                out.println("(" + st[sti].getFileName());
                if(st[sti].getLineNumber() < 1){
                    out.print("Native method");
                }else{
                    out.print(":" + st[sti].getLineNumber());
                }
                out.println(")");
            }
            
            out.println("");
            cnt++;
        }
    }catch(Exception e){
        out.println(br + "err " + e + br);
    }
    



%>

Пример вывода:

121 Поток-40, приоритет: 6, состояние: ОЖИДАНИЕ, идентификатор: 134, шестнадцатеричный: 86, живой: истина, демон: ложь прерван: ложь, демон: ложь.

java.lang.Object.wait (собственный метод Object.java)
java.lang.Object.wait (Object.java: 485)
org.jpos.iso.ISOMUX$Receiver.run (ISOMUX.java: 326)
java.lang.Thread.run (Thread.java :662)

122 Thread-48, приоритет: 5, состояние: TIMED_WAITING, идентификатор: 142, шестнадцатеричный: 8e, живой: true, демон: false, прерванный: false, демон: false.

java.lang.Thread.sleep (собственный метод Thread.java)
org.jpos.apps.qsp.QSP.monitorConfigFile (QSP.java:301)
org.jpos.apps.qsp.QSP.run ( QSP.java:346)
java.lang.Thread.run (Thread.java:662)

person tgkprog    schedule 04.09.2012