FWIW, the equivalent in FreeBSD is 'procstat -kk $PID' Eg:<p><pre><code> % procstat -kk 5592
PID TID COMM TDNAME KSTACK
5592 103222 less - </code></pre>
mi_switch+0xe1 sleepq_catch_signals+0x405
sleepq_wait_sig+0xf _cv_wait_sig+0x154 tty_wait+0x1c
ttydisc_read+0x1f2 ttydev_read+0x64 devfs_read_f+0xdc
dofileread+0x95 sys_read+0xc3 amd64_syscall+0x369
fast_syscall_common+0x101<p>procstat can also do interesting things, like show current rusage state:<p><pre><code> % procstat -r 5592
PID COMM RESOURCE VALUE
5592 less user time 00:00:00.010805
5592 less system time 00:00:00.002444
5592 less maximum RSS 3172 KB
5592 less integral shared memory 192 KB
5592 less integral unshared data 80 KB
5592 less integral unshared stack 256 KB
5592 less page reclaims 199
5592 less page faults 0
5592 less swaps 0
5592 less block reads 4
5592 less block writes 0
5592 less messages sent 0
5592 less messages received 0
5592 less signals received 0
5592 less voluntary context switches 59
5592 less involuntary context switches 0</code></pre>
If you are running java instead of a c program the proc stacktrace shows you just the virtual machine state. You can still get a stacktrace of your java threads[1].<p>How about other languages?
Python, ruby?<p>[1] <a href="https://stackoverflow.com/questions/4876274/kill-3-to-get-java-thread-dump" rel="nofollow">https://stackoverflow.com/questions/4876274/kill-3-to-get-ja...</a>
Nicely formatted site. Anyone know if/what static site generator/theme is being used? Couldn't find anything on the footer, site tags, or his GitHub that would reveal that...
Note, the GNU debugger (gdb) can attach to running processes. This should give you a stack trace with readable addresses, cf. <a href="https://stackoverflow.com/questions/2308653/can-i-use-gdb-to-debug-a-running-process" rel="nofollow">https://stackoverflow.com/questions/2308653/can-i-use-gdb-to...</a>
I want this capability for embedded ARM systems. I should be able to call a function to have the current stack trace printed:<p><a href="https://communities.mentor.com/thread/16468" rel="nofollow">https://communities.mentor.com/thread/16468</a>
Instead of teaching people how to do this portably across all UNIX-like systems, by sending SIGABRT to the process, the article is steeping them in GNU/Linux only way of doing things. This feels exactly like the '90's of the past century, where a lot of people with computer-related careers had no idea that there were other operating systems and other ways of doing things (better): an intel-based PC tin bucket with Windows was the one and only truth for them. Now it's exactly the same except Windows has been replaced with GNU/Linux. 28 years later and the only advancement some people have made is running the proverbial sed 's/Windows/Linux/g'.