Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using /proc to get a process' current stack trace

ops.tips

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Using /proc to get a process' current stack trace

#41

Post by monocasa »

jwilk wrote: post #40
monocasa wrote: post #31

Earlier quoted context omitted.

I can't think of a single OS that gives you kernel stack traces on SIGABRT. Can you disambiguate CTF? I only know that as capture the flag, which doesn't really make sense here. Edit: ok, I figured it out. No theyre not going to give you that raw information because it's a kernel ASLR bypass. You can totally get all the same information with the dwarf symbols, but you're going to have to opt in on a kernel for it to…

Tell us what you figured out…

Haha sorry. It's a Solaris version of DWARF or pdb style metadata for their kernel.

https://docs.oracle.com/cd/E19253-01/816-5041/syntax-20/inde...

For that to be useful, you'd need the addresses in question, which is why it'd be an ASLR bypass. The kernel needs to give higher level information by default so it can sanitize the output.

And the debugging symbols exist on Linux anyway, they're just DWARF (which ironically is the more standards compliant way as opposed to CTF).

Re: Using /proc to get a process' current stack trace

#42

Post by oneanddone »

someguydave wrote: post #24
justinsaccount wrote: post #9

Earlier quoted context omitted.

How's the support for bluetooth on openbsd these days?

Also, how many of the aforementioned bsds use drivers that were ported from the Linux kernel tree?

BSD user here. Of course there is porting occurring, but this is the nature of open source, is it not? Oftentimes, the BSD devs will take whatever hardware specs they can get and code something from that. OpenBSD frequently writes drivers that are orders of magnitude smaller than comparable Linux drivers, while getting the same functionality. NVIDIA drivers are but one example. Some hardware vendors are generous with hardware specs for OSS, most are not. OpenBSD, as an example, will not have any GPL'd code in the base OS, as it's not truly free. Ports are another issue.

Re: Using /proc to get a process' current stack trace

#44

Post by sctb »

Annatar wrote: post #2

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 Wi…

Sounds like a good post for Hacker News! If you find it or write it, please go ahead and submit.

Re: Using /proc to get a process' current stack trace

#45

Post by dman »

someguydave wrote: post #24
justinsaccount wrote: post #9

Earlier quoted context omitted.

How's the support for bluetooth on openbsd these days?

Also, how many of the aforementioned bsds use drivers that were ported from the Linux kernel tree?

I dont understand how ports help / hinder usability of drivers. Could you please elaborate?

Re: Using /proc to get a process' current stack trace

#46

Post by astral303 »

lixtra wrote: post #11

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]. How about other languages? Python, ruby? [1] https://stackoverflow.com/questions/4876274/kill-3-to-get-ja...

Also `jstack` from the shell

Re: Using /proc to get a process' current stack trace

#47

Post by someguydave »

dman wrote: post #45
someguydave wrote: post #24

Earlier quoted context omitted.

Also, how many of the aforementioned bsds use drivers that were ported from the Linux kernel tree?

I dont understand how ports help / hinder usability of drivers. Could you please elaborate?

They don't. However, they do reduce the ability of the target O/S of the port to claim that it isn't a clone of Linux. The top-level post was complaining that people don't consider non-Linux O/S, and then failed to offer compelling alternatives.

Re: Using /proc to get a process' current stack trace

#49

Post by lelf »

drewg123 wrote: post #12

FWIW, the equivalent in FreeBSD is 'procstat -kk $PID' Eg: % procstat -kk 5592 PID TID COMM TDNAME KSTACK 5592 103222 less - 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 procstat can also do interesting things, like show current rusage stat…

Also you can easily get both kernel- and user-level stack trace with dtrace.

Re: Using /proc to get a process' current stack trace

#50

Post by monocasa »

stefan_ wrote: post #32
jhallenworld wrote: post #15

I want this capability for embedded ARM systems. I should be able to call a function to have the current stack trace printed: https://communities.mentor.com/thread/16468

The most widely distributed embedded ARM system software in the world, Android, offers this. They use mini debug info (normal debug info sections compressed, IIRC) and then you can signal a daemon in the background to do a stacktrace on your application. Not on production images, though.

> The most widely distributed embedded ARM system software in the world, Android

[citation needed]

Also, when talking about embedded systems, people aren't normally talking about full Linux distros.

Post reply on HN