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

31–40 of 69 posts

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

#31

Post by monocasa »

Annatar wrote: post #28
monocasa wrote: post #6

Earlier quoted context omitted.

This mainly about grabbing the kernel stack trace. There's not a portable way to do that. Also, doesn't SIGABRT generally kill off the process?

A kernel should always be compiled with symbols / source code inside of it -- that the Linux kernel doesn't have full support for CTF says more about it than it does about CTF. Yes, a SIGABRT will get you a core file and will kill a process, but if your process is hanging in an endless loop (like the author's was), one already has far bigger problems, and keeping such a process running will not amount to much.

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

Edit2: bitching about how people aren't using portable Unix techniques, and then citing features that are Solaris specific isn't a great look.

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

#32

Post by stefan_ »

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.

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

#33

Post by monocasa »

pjmlp wrote: post #26
monocasa wrote: post #21

Earlier quoted context omitted.

...the article doesn't say unix at all with the exception of when the go code at the end is in fd_unix.go in it's source trace.

I was supporting the parent post about doing stuff in Linux only way, instead of UNIX in general.

There isn't a UNIX way for grabbing the kernel stack trace.

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

#34

Post by monocasa »

Annatar wrote: post #29
jstanley wrote: post #23

Earlier quoted context omitted.

Even if that were the case, a free software hegemony is surely better than a proprietary Microsoft hegemony.

Write for yourself -- I've no problem paying Apple Computer for a solution which I plop down on a table, turn on, and start using immediately after that without having to fiddle with it.

They regularly fuck up security so much that you aren't getting what you pay for. In the last major release they both allowed anyone to login as root by just not supplying a password, and writing the FDE password on the disk in plaintext as the "hint" instead of the actual hint.

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

#35

Post by geofft »

Annatar wrote: post #30
geofft wrote: post #25

Earlier quoted context omitted.

> Instead of teaching people how to do this portably across all UNIX-like systems, by sending SIGABRT to the process Sending SIGABRT doesn't do what the article is talking about, on any UNIX. Perhaps you would learn something from listening to the kids these days, like the distinction between a kernel stack and a userspace stack.

My illumos based kernel begs to differ. And I'll listen to the kids when they actually start understanding what they are doing and why they are doing it, that is, when they learn how to use a computer.

Can you post a transcript of doing so and getting the kernel stack? On not just Illumos but other UNIXes, to demonstrate that it is portable?

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

#36

Post by benfrederickson »

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

I wrote something that will get you the python interpreter stack from any running cpython process : https://github.com/benfred/py-spy/ , and rbspy can do the same for ruby https://github.com/rbspy/rbspy

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

#38

Post by cthalupa »

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 Joyent, even with the Samsung acquisition, does not have the resources to keep it going in any meaningful way for anyone beyond themselves and people who have the exact same usecase as them. Things like lx branded zones are clever. I miss SMF, and am not a fan of systemd. But bpf is better than dtrace. Container management is easier than zone management. I've got less bugs dealing with KVM on Linux than I ever did on SmartOS. I spend less time compiling things from source and having to find random patch files to make things work. I know plenty about Solaris and SmartOS and HPUX and AIX and the BSDs and I don't think anyone is making the incorrect choice in deciding to learn Linux over any other UNIX-like.

That ship has sailed, man. And there's no compelling reason that it shouldn't have.

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

#40

Post by jwilk »

monocasa wrote: post #31
Annatar wrote: post #28

Earlier quoted context omitted.

A kernel should always be compiled with symbols / source code inside of it -- that the Linux kernel doesn't have full support for CTF says more about it than it does about CTF. Yes, a SIGABRT will get you a core file and will kill a process, but if your process is hanging in an endless loop (like the author's was), one already has far bigger problems, and keeping such a process running will not amount to much.

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…
Post reply on HN