jstack(1)

✨ jstack — bestie's guide to snooping on Java threads ✨

okay so real talk, this one's from the Troubleshooting Tools section of the jstack(1) manual, and honestly? it's giving detective energy. 🔍

---

💖 NAME 💖

jstack — prints Java thread stack traces for a Java process, a core file, or a remote debug server. no cap, it literally shows you what every thread is doing.

⚠️ heads up bestie: this command is experimental and unsupported. like, it's the cool mysterious transfer student of the JDK. 🫶

---

🦋 SYNOPSIS 🦋

jstack [ options ] pid

jstack [ options ] executable core

jstack [ options ] [ server-id@ ] remote-hostname-or-IP

and here's what all that stuff means, one by one, because i would never leave you guessing 💅

• options — the command-line options. see the Options section down below, i gotchu.
• pid — the process ID you want the stack trace for. it has to be a Java process, no exceptions. wanna see which Java processes are even running on the machine? that's a jps(1) job, bestie.
• executable — the Java executable that the core dump came from.
• core — the core file you want the stack trace printed for.
• remote-hostname-or-IP — the hostname or IP address of the remote debug server. peep jsadebugd(1) for that one.
• server-id — an optional, unique ID you use when there are multiple debug servers running on the same remote host. so they don't get their vibes confused. 🎀

---

🌸 DESCRIPTION 🌸

so jstack prints Java stack traces of Java threads for a specified Java process, core file, or remote debug server. iconic behaviour, honestly.

for every single Java frame, you get the full class name, the method name, the byte code index (BCI), and the line number — when it's available, of course.

now, add the -m option and it gets so much richer: jstack prints both Java and native frames of all threads, with the program counter (PC). and for each native frame, you also get the closest native symbol to PC, when available. the way that's actually useful 😭

⚠️ real talk though: C++ mangled names do not get demangled. nope. if you want demangled names, pipe the output of this command to c++filt. that's the move.

and if the specified process is running on a 64-bit Java Virtual Machine, you might need to specify the -J-d64 option, like this:

jstack -J-d64 -m pid

🫶 note, and this one matters: this utility is unsupported and might not be available in future release of the JDK. and on Windows Systems where the dbgeng.dll file is not present, Debugging Tools For Windows must be installed so these tools work. also the PATH environment variable needs to contain the location of the jvm.dll that's used by the target process — or the location from which the crash dump file was produced. for example: text set PATH=<jdk>\jre\bin\client;%PATH%

---

💅 OPTIONS 💅

• -F — force a stack dump when jstack [-l] pid does not respond. it's the "i'm not asking anymore" option. 🔥
• -l — long listing. prints extra info about locks, like a list of owned java.util.concurrent ownable synchronizers. see the AbstractOwnableSynchronizer class description at http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/AbstractOwnableSynchronizer.html — yes the whole URL, i'm not truncating it, that would be rude. 👑
• -m — prints a mixed mode stack trace that has both Java and native C/C++ frames. the full picture, no crumbs. ✨
• -h — prints a help message.
• -help — prints a help message. (yes, same as -h, they're twins, let them live 😌)

---

💀 KNOWN BUGS 💀

in mixed mode stack trace, the -m option does not work with the remote debug server. that's it, that's the bug. not me finding out the hard way 🙈

---

🌈 SEE ALSO 🌈

• pstack(1)
• C++filt(1)
• jps(1)
• jsadebugd(1)

---

okay and finally, the receipts 🎀 — this page is from JDK 8, dated 21 November 2013, and lives in the Troubleshooting Tools manual. go forth and stack-trace, bestie, you're literally the main character of debugging now 💜🦋✨