4

In Linux 2.6.32-32, is there a way to find the following information about a thread programmatically in a pthreads program? I need: run count, stack pointer, stack start/end, stack size, stack usage. Something like ThreadX, I guess, but within a program. Thanks.

Fiddling Bits
  • 8,712
  • 3
  • 28
  • 46
Dervin Thunk
  • 19,515
  • 28
  • 127
  • 217

2 Answers2

6
  • pthread_getattr_np() should give you the pthread attributes of a thread
  • pthread_attr_getstack() returns the stack address and size
  • I don't know what you mean by run count.
  • For the stack pointer of a thread different than your current one you might need to use ptrace. Once you have it, you can use it to do the maths for determining how much of the stack is used.

For obtaining your own stack pointer you can always do something along the lines of:

mword sp;
asm volatile ("mov %esp, $0" : "=r"(sp));
BjoernD
  • 4,720
  • 27
  • 32
  • This is a great answer, thank you. Maybe you can help me with sthg: `pthread_attr_getstack()` returns "0" for size and address when you let the system use defaults. Is there a way to return this information without setting them first through `pthread_attr_setstackaddr()` and size? Thanks again. – Dervin Thunk Jul 14 '11 at 23:27
  • @Dervin, Stack size can be unbounded. On Linux, typically you'll start out with one stack page plus a few guard pages; if you fault on a guard page, the stack is expanded. The thread may continue growing its stack until it hits some other mapping, at which point it'll SIGBUS. This'll be even harder to account for soon - there is work ongoing for discontiguous stacks; when you run out of space in your stack, it'll just switch you to a new stack segment; when the function returns, it'll switch back to the old stack. – bdonlan Jul 14 '11 at 23:29
  • Hmm. Defaults may vary by system I'm afraid. For the stack size there appears to be a resource limit RLIMIT_STACK which you can query: http://linux.die.net/man/2/setrlimit No idea about how to find the start from that. You might have a function early on in the thread that reads the initial stack pointer and then assuming that stacks are properly aligned to some address tries to guess the stack region's base address. That's just handwaving, though. – BjoernD Jul 14 '11 at 23:34
  • @bdonlan: This is not true for threads. Thread stacks are necessarily bounded because they must reserve address space. Otherwise any other random allocation could butt against them and prevent expansion, leading to random crashes. – R.. GitHub STOP HELPING ICE Jul 14 '11 at 23:37
  • @R, the first thread in a process is still a thread, and discontiguous stacks are being developed precisely for the reason you stated. There's also nothing wrong with reserving some reasonable amount of stack space, but still allowing for growth via guard pages. My point is, there isn't necessarily a fixed stack limit to a thread, and even if there is, you can't necessarily get the current stack usage/free stack based on a comparison with the stack pointer. – bdonlan Jul 14 '11 at 23:42
  • @bdonlan: I think, Dervin is fine knowing how much memory is reserved for the stack. – BjoernD Jul 14 '11 at 23:46
4

As an addendum to BjoernD's answer, you can obtain context switch counts and total run time using the getrusage call with RUSAGE_THREAD. You cannot obtain information on the raw number of time slices executed; this information is not tracked in the first place.

bdonlan
  • 224,562
  • 31
  • 268
  • 324
  • Thank you for this. I had to accept BjoernD's answer because he answered first and right on, but I've upvoted you, and I've also upvoted another one of your answers (in another question), so it's mostly identical to being accepted :) – Dervin Thunk Jul 14 '11 at 23:35