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

61–69 of 69 posts

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

#61

Post by markjdb »

Annatar wrote: post #53
monocasa wrote: post #41

Earlier quoted context omitted.

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

CTF is just a specially compressed format and specification of embedding the source code into the binary; it's a complement to DWARF format, not the format itself. The documentation you cite even says it's similar, meaning that it's not DWARF.

The main purpose of CTF is to provide a succinct representation of the graph of C types used in a program. It's generated from DWARF; anything encoded in the CTF section can also be found in DWARF info. CTF has nothing to do with "embedding source code" and isn't useful for stack unwinding or symbol resolution.

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

#62

Post by scottlamb »

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...

> If you are running java instead of a c program the proc stacktrace shows you just the virtual machine state.

No, this is a _kernel_ backtrace: what is happening in kernelspace on behalf of your process. If the work is being done in userspace (that is, in state R; the thread isn't in a syscall or page fault handler), you'll see essentially nothing here. I just tried it on a userspace busylooper and got this:

    [] exit_to_usermode_loop+0x57/0xb0
    [] prepare_exit_to_usermode+0x20/0x30
    [] 0xfffffffffffffff
Java, Python, C++ nothings all look pretty similar.

If you want a userspace stack trace, you need a different tool. If you're using an interpreted (or perhaps JITted) language, yes, you probably want something language-specific.

Also note the current stack trace is a per-thread concept, not a per-process one. If you're looking at a multithreaded program, you want to target the thread(s) of interest with "/proc//task//stack".

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

#63

Post by geofft »

monocasa wrote: post #60
Annatar wrote: post #52

Earlier quoted context omitted.

It's not a Solaris specific feature; FreeBSD has it as well: https://www.freebsd.org/cgi/man.cgi?query=ctf&apropos=0&sekt... Linux is the one lagging behind, as usual. How is embedding source code an "ASLR bypass"?

OK, it's a dtrace thing that got ported to FreeBSD with dtrace. That still doesn't make it "Unix" any more than Linux's proc access. Embddeding debugging information in a way that allows to you to use it (ie. in a way that you'd care about the format as an end user) implies giving you kernel addresses, which implies an ASLR bypass. If it's an implementation detail, then DWARF works great.

And if "FreeBSD has it too" is our standard for portable UNIX features, then /proc counts thanks to linprocfs.

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

#65

Post by Annatar »

geofft wrote: post #63
monocasa wrote: post #60

Earlier quoted context omitted.

OK, it's a dtrace thing that got ported to FreeBSD with dtrace. That still doesn't make it "Unix" any more than Linux's proc access. Embddeding debugging information in a way that allows to you to use it (ie. in a way that you'd care about the format as an end user) implies giving you kernel addresses, which implies an ASLR bypass. If it's an implementation detail, then DWARF works great.

And if "FreeBSD has it too" is our standard for portable UNIX features, then /proc counts thanks to linprocfs.

/proc on Linux wasn't implemented like /proc is on other operating systems; it's the only /proc implemented that way. The interface, if it could even be called that, is completely proprietary to Linux; output is ad hoc with no consistency. As usual.

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

#66

Post by Annatar »

monocasa wrote: post #60
Annatar wrote: post #52

Earlier quoted context omitted.

It's not a Solaris specific feature; FreeBSD has it as well: https://www.freebsd.org/cgi/man.cgi?query=ctf&apropos=0&sekt... Linux is the one lagging behind, as usual. How is embedding source code an "ASLR bypass"?

OK, it's a dtrace thing that got ported to FreeBSD with dtrace. That still doesn't make it "Unix" any more than Linux's proc access. Embddeding debugging information in a way that allows to you to use it (ie. in a way that you'd care about the format as an end user) implies giving you kernel addresses, which implies an ASLR bypass. If it's an implementation detail, then DWARF works great.

Again, which bypass? If you attach to a process you will see machine code and it will be stored at memory addresses.

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

#67

Post by Annatar »

cthalupa wrote: post #38
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…

SIGABRT in most places is not going to both get the stack trace and keep the process running. In fact, I would argue that if you are running something that continues working after it receives a signal telling it to /abort/, it's a bug. What do the word abort mean to you? As for SmartOS, as someone who ran it at home and in production for years: Keep flying that flag, I guess. I liked it. But I also realized that Joye…

"Container management is easier than zone management."

Linux has no containers, cgroups aren't anything conceptually close to zones. There are 56 different solutions to virtualization on Linux, all competing, mainly because everyone there is still flapping on deployment and lifecycle management. We'll just have to disagree and vehemently at that.

As for Joyent having no resources: you debug it and fix it yourself. That's precisely how Linux got to be the hegemony that it is today. Oh, how quickly we forget, how short our memory is...

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

#68

Post by lathiat »

chaosfox wrote: post #48
_pmf_ wrote: post #18

My favorite proc hack: https://news.ycombinator.com/item?id=17061499

check out progress: https://github.com/Xfennec/progress

That's a cool tool.. I did that manually many times and always thought I should write a tool. Glad to see it exists already :)

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

#69

Post by curtis86 »

indigodaddy wrote: post #43

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...

Agreed! It looks like Hugo and possibly this theme: https://themes.gohugo.io//theme/cocoa-eh-hugo-theme/blog/exa...
Post reply on HN