Hi!
I have got some questions about mdb and handling processes and threads.
QUESTION:
Given a debugee process and an mdb process.
How can I check or set thread and mutext states in the debugee process from the
mdb process?
My approach would be program an mdb module using kernel calls e.g.
thr_{resume,suspend} to set a thread state from the mdb process. However I
doubt I could pursue this way since the debugee process is actually halted
_and_ I would be crossing process boundaries (from mdb process to debugee
process)
What is your advice on this? How can I inspect/change a debugee process' thread
and mutex state from mdb?
LONG VERSION: This is what I need this functionality for (the bigger picture)
I would like to use mdb as a deadlock detector/provoker a.k.a model checker.
Specifically I would like to employ mdb to check a process/program (the debugee
process) running several threads. within the debugee process environment, I
would like mdb to
- automatically suspend/resume the threads (and then let one thread
execute on its own, with the rest of the threads suspended)
- automatically set and release breakpoints (ok, I know how to do that.)
- and then check/alter the thread state (e.g. locks/mutexes held/waiting...)
The thread suspend/resume and mutex/lock state checking/changing tasks are
somehow beyond pure mdb (both cli and api) and might involve knowledge of
internal kernel structures (e.g. checking lock and thread states, manipulating
thread suspend/resume in the scheduler).
So here come my more detailed questions:
- For thread suspend/resume there are some thr_{suspend,resume} solaris kernel
calls.
Can I use these calls within one process (the mdb process) to manipulate the
threads of
another process (the debugee program?)
- If this is not possible, could you give me any hints regarding kernel
structures on how to
check or set a thread state in a debugged process?
- How can I check a program's lock/mutex states (again checking would be done
from the
mdb process for a lock/mutex state in another process)
Thank you for your precious time,
Regards
Thomas Lemm
This message posted from opensolaris.org
