CODEWITHSUNDEEP
c++cunixstack-trace
John Humphreys
John Humphreys

Reputation: 39304

Stack trace running UNIX application

How can I perform a live stack trace on a running UNIX applicaiton, and are there any utilities that are useful in digesting the stack trace once its done?

I'm looking to see if any functions are getting called more often than I would have expected them to be - the application works fine, it just recently slowed down and it doesn't appear that anything else in the system is responsible (no other processes are running with unusual memory/processor usage).

Upvotes: 3

Views: 872

Answers (5)

Luc Danton
Luc Danton

Reputation: 35449

Your debugger may have the functionality to attach to a running process. With gdb this looks like

$ gdb path/to/exec 1234

where 1234 is the PID of the running process.

(But consider those answers that direct you to a profiling utility.)

Upvotes: 0

ConcernedOfTunbridgeWells
ConcernedOfTunbridgeWells

Reputation: 66662

Profiling tools will show what bits of the program are taking up the CPU time. If you have to dig deeper, you may need other tooling. Depending on what species of unix you're after, the tools will vary, as this is sometimes quite platform specific. This article discusses process monitoring on Linux. Different versions of unix may have different sets of utilities for functions that have to interact with the kernel (e.g. Dtrace for Solaris). Some do work across platforms.

Upvotes: 2

celavek
celavek

Reputation: 5715

I'm guessing you want this at runtime without any debugger involvment. For that you could use glibc's backtrace functions. Documentation here and here(assuming Linux) just to get you started. This Linux Journal article might be of help also.

Upvotes: 0

NPE
NPE

Reputation: 500683

How can I perform a live stack trace on a running UNIX applicaiton

gcore can be used to grab a core file for a live process. This will give you a snapshot of the stack traces for all threads. This approach may, however, be a little too heavyweight for your needs.

If the suspect functions are system calls, you could try using strace to see what's going on.

In any case, I think the first port of call should be a profiler, such as gprof.

Upvotes: 2

Earlz
Earlz

Reputation: 63875

Have you tried using an actual profiler on your application? This will help you much more than just a stack trace. Usually you just have to compile your application with profile information. Then you can run it and use the information written to determine in which functions the most time is being spent, number of calls, etc.

Upvotes: 2

Related Questions