Pstack a Process on Osx 10.9

Pstack a process on OSX 10.9

sudo /usr/libexec/stackshot -i -u -p <pid>

This appends a stack trace of all threads of the process in question to the file /Library/Logs/stackshot-syms.log . Consider to remove the file stackshot-syms.log before calling stackshot. See: stackshot(1)

Note: stackshot is no longer included with OS X 10.11 EL Capitan.
Use the lldb debugger instead:

echo "thread backtrace all" | lldb -p <pid>

lldb is part of the command line developer tools. If you don't have lldb on your machine, a popup will help with installing XCode.

Program doesn't stop after returning 0 from main

Or is the problem in the rest of the code?

Possibly. Perhaps you've corrupted your stack somehow, so that you're "returning" from main to someplace you didn't expect. We can't really know without an complete, verifiable example.

How can I make it finish after returning 0?

You can use the kill command on MacOS to terminate it forcefully. Using the GUI task manager may or may not work.

But perhaps a more effective course of action would be to attach a debugger to the process and see what it's actually doing.

You could read this explanation on how to do this on MacOS with XCode - but I don't use MacOS, so I wouldn't know. Also, @SergeyA graciously suggests trying using pstack to get the process' current stack. Of course, if the stack has been garbled, there's no telling what you'll actually get.

Make sure the application is compiled with debugging information included.

Finally - it's probably better to run the program with a debugger attached in the first place, and set a breakpoint at the last cout << line.

Golang: Cannot get gdb working for Go programs using C libraries

You're experiencing issue 5221. A related question is this one.

This problem has been partially fixed for ELF files but remains open for the Mach format
which you are using. So I guess you have to wait for go 1.3 or the appropriate fix from tip
to have this resolved.

Basically the problem is that the linker you use for the compiled .c files does not extract
the debug info from the object (.o) files but refers to them. As they're deleted after the
build process, gdb can't read them.

As a workaround, you might try to run go build -work for go-glfw so that the build
directory is not removed and the object files remain accessible.

---

Related Topics