Bug 183511 - Cannot run jstack on AS 4
Cannot run jstack on AS 4
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-01 11:58 EST by Mikhail Garber
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-09 11:34:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of strace -f jstack pid (743.46 KB, application/binary)
2006-03-03 17:16 EST, Mikhail Garber
no flags Details
output of strace -f jstack on other OS (634.83 KB, application/binary)
2006-03-07 10:52 EST, Mikhail Garber
no flags Details

  None (edit)
Description Mikhail Garber 2006-03-01 11:58:35 EST
Description of problem: 
unable to run jstack (Sun's reporting tool) on any Java process on AS 4 systems.
Runs fine on earlier versions of RedHat, Fedora Core 4 and on current non-RedHat
Linuxes.


Version-Release number of selected component (if applicable):

Red Hat Enterprise Linux AS release 4 (Nahant Update 1)
Sun JDK 1.5.0.06

How reproducible: Always

Steps to Reproduce:
1. run any Java program using Suns JDK
2. run {where java is}/bin/jstack pid-of-the-java-process
3.geet exception
  
Actual results:
Attaching to process ID 29417, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 1.5.0_05-b05
Thread 30393: (state = IN_NATIVE)
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:134)
	at
sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebuggerLocal.java:437)
	at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:48)
	at
sun.jvm.hotspot.runtime.linux_x86.LinuxX86JavaThreadPDAccess.getCurrentFrameGuess(LinuxX86JavaThreadPDAccess.java:75)
	at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:252)
	at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:211)
	at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:50)
	at sun.jvm.hotspot.tools.JStack.run(JStack.java:41)
	at sun.jvm.hotspot.tools.Tool.start(Tool.java:204)
	at sun.jvm.hotspot.tools.JStack.main(JStack.java:58)
Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed
for a lwp


Expected results:

should print list of threads and what they are doing

Additional info:
Comment 1 Phil Knirsch 2006-03-02 04:56:29 EST
That sounds more like a glibc problem. The component basesystem refers to the
package basesystem which provides a skeleton for a Red Hat Linux system.

Reassigning bug to glibc.

Read ya, Phil
Comment 2 Jakub Jelinek 2006-03-02 06:39:04 EST
Can you please attach strace -f output of the jstack process?
It can be anything, from a kernel problem, glibc or hotspot bug.
Comment 3 Mikhail Garber 2006-03-03 17:16:52 EST
Created attachment 125628 [details]
output of strace -f jstack pid

output of strace -f jstack pid
Comment 4 Roland McGrath 2006-03-07 04:34:04 EST
All the indications in that trace point to a misuse of ptrace, or perhaps a
problem with ptrace or some other kernel issue.  There is no sign of anything
relating to glibc here.  I wonder what the trace from a system where it works
right shows.  This trace makes it look like the program is not doing the right
things to handle multiple threads via ptrace at all.
Comment 5 Mikhail Garber 2006-03-07 10:52:12 EST
Created attachment 125760 [details]
output of strace -f jstack on other OS

As requested, attaching output of strace -f jstack pid from other Linux as
similar to RedHat as I could find: CentOs running 2.6.9-22.EL (where jstack
works as expected)
Comment 6 Roland McGrath 2006-03-07 19:39:00 EST
That trace shows it writing out the same sort of error messages you cite as
being the problem.
Comment 7 Mikhail Garber 2006-03-08 10:01:02 EST
you are right, the format is the same - a Java stack trace. 

Only in the "bad" case it represents the actual exception thrown from the tool
with the message "get_thread_regs failed for a lwp" and in the "good" case it is
just a stack trace showing what this thread is doing at the moment. Example of
"good" output:

Thread 3947: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.Object.wait() @bci=2, line=474 (Interpreted frame)
 - org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run() @bci=26, line
=656 (Interpreted frame)
 - java.lang.Thread.run() @bci=11, line=595 (Interpreted frame)
Comment 8 Roland McGrath 2006-03-08 14:24:18 EST
Your second trace shows writing out these messages:

Error occurred during stack walking:
sun.jvm.hotspot.debugger.DebuggerException:
sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp

etc.  Those are what I've described as the same sort of error messages you've
cited as being the problem.  Please attach a trace from a run that does not
produce such errors.
Comment 9 Jakub Jelinek 2006-05-09 11:34:33 EDT
No response in 2 month and no signs of a bug in anything but jstack (its
incorrect use of ptrace).

Note You need to log in before you can comment on or make changes to this bug.