Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not sure just how much you do/don't understand, or how much others will/won't understand, so I'll run through line by line:

    PID=$!
grabs the PID of the process you just spawned (in the background, with &) into shell variable PID

    CMDLINE="!-2"
grabs the full line you just ran (before the line storing PID) with shell history expansion

    CMD=${CMDLINE%% *}
expands the CMDLINE variable, replacing everything after the first space (so CMD now has "cat") with bash trickery

    WCHAN=$(cat /proc/${PID}/wchan)
grabs the name of the currently executing syscall for the process (at least, according to http://www.lindevdoc.org/wiki/proc/pid/wchan)

    echo "command: ${CMD}, pid: ${PID}, wchan: ${WCHAN}"
prints the info we've grabbed

    strace -p ${PID}
connects a trace to the process to see what it's doing

    gdb ${CMD} ${PID}
connects to the process (gdb needs program name and can be given a pid to connect to)

    (gdb) disassemble
prints the actual (assembler) code being run. In this case, I think all we get from the output is that it's in fact in the middle of some syscall - you'd have to check registers and syscall tables to determine which.

As others have mentioned, much of this is less useful than implied in the face of an actual wedged process.

Tangentially, using gdb to attach to running processes is a very powerful technique - I've been able to get line numbers out of running bash scripts.



Thank you for that! Makes it clear, I guess I have to properly learn gdb's output... I work in bioinformatics, we never go that low.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: