FULL PRODUCT VERSION :
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux fhossain 2.6.24-23-generic #1 SMP Mon Jan 26 01:04:16 UTC 2009 x86_64 GNU/Linux

EXTRA RELEVANT SYSTEM CONFIGURATION :
The core file was generated using gcore or using gdb
GNU gdb 6.8-debian.

A DESCRIPTION OF THE PROBLEM :
Both jstack and jdb has the same problem trying to display stacktrace from a core file generated with gcore or gdb. The problem seems to exist with 1.5 too. Jstack is able to show proper stack trace when attaching to the process directly but not able to show stacktrace when attaching to a generated corefile. Also, jmap has no problems generating memory dumps from the same core file.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
 To reproduce run java process and generate core file with either gcore or gdb. Then use jstack to attach to the core.

% java GCoreTest
% jps -m
Note processid of GCodeTest
% jcore <pid>
% jstack `which java` core.<pid>

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Full stack trace and no error.
ACTUAL -
$ ./jstack 23144
2009-02-05 21:27:12
Full thread dump Java HotSpot(TM) Server VM (10.0-b23 mixed mode):

"Attach Listener" daemon prio=10 tid=0x08145800 nid=0x5a96 waiting on condition [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"Low Memory Detector" daemon prio=10 tid=0x08139400 nid=0x5a74 runnable [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"CompilerThread1" daemon prio=10 tid=0x08137c00 nid=0x5a73 waiting on condition [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"CompilerThread0" daemon prio=10 tid=0x08135400 nid=0x5a72 waiting on condition [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x08134000 nid=0x5a71 runnable [0x00000000..0xb02c2aa0]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x080ff400 nid=0x5a70 in Object.wait() [0xb0352000..0xb0352e40]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0xeda30b30> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
- locked <0xeda30b30> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x080fe000 nid=0x5a6f in Object.wait() [0xb03a3000..0xb03a3ec0]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0xeda30a38> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0xeda30a38> (a java.lang.ref.Reference$Lock)

"main" prio=10 tid=0x08058c00 nid=0x5a69 waiting on condition [0xf7d91000..0xf7d91218]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at GCoreTest.main(GCoreTest.java:10)

"VM Thread" prio=10 tid=0x080fb000 nid=0x5a6e runnable

"GC task thread#0 (ParallelGC)" prio=10 tid=0x0805f800 nid=0x5a6a runnable

"GC task thread#1 (ParallelGC)" prio=10 tid=0x08060800 nid=0x5a6b runnable

"GC task thread#2 (ParallelGC)" prio=10 tid=0x08061c00 nid=0x5a6c runnable

"GC task thread#3 (ParallelGC)" prio=10 tid=0x08062c00 nid=0x5a6d runnable

"VM Periodic Task Thread" prio=10 tid=0x0813ac00 nid=0x5a75 waiting on condition

JNI global references: 583


ERROR MESSAGES/STACK TRACES THAT OCCUR :
Thread 21376: (state = BLOCKED)
Error occurred during stack walking:
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.getThreadIntegerRegisterSet(LinuxDebuggerLocal.java:443)
at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:65)
at sun.jvm.hotspot.runtime.linux_x86.LinuxX86JavaThreadPDAccess.getCurrentFrameGuess(LinuxX86JavaThreadPDAccess.java:92)
at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:255)
at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:214)
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)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Any java class can be use but here is one that will keep the server running to take coredumps.
public class GCoreTest {

    /**
     * @param args
     */
    public static void main(String[] args) {
    // TODO Auto-generated method stub
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException ie) {}
        
        System.exit(0);
    }
}

---------- END SOURCE ----------

SUPPORT :
YES