Re: [Bashdb-pydb] Some possible thread debug additions

[R. B. <ro...@pa...>]

Gee, this is quite a bit of information. I'm not sure how to best make us=
e
of it. I was offering a very limited set of choices which might be added
sometime in the very vague future. Basically it sounds like, "step thread=
"
and "next thread" are useful, although no doubt there will be confusion
that this means to block all other threads and it doesn't.

Adding a location specification to the "continue" command is pretty easy
to do. Gdb doesn't have it on its "continue" command, but Perl's debugger
does as does the bash debugger (as well as probably other debuggers).
However it is also true, as you note, it's also pretty easy to add via an
alias.

One can't preempt a thread in Python, so a gdb-style "thread" command is
impossible. The closest one can get is to switch threads after performing
the statement after one is currently stopped at. And even here this has
problems. First, unless one is stopped in all threads that the debugger
has control over, it can't be done reliably. Second, even if the debugger
has control over all threads, trying to restrict execution to a particula=
r
thread and then running the statement that you are stopped at could
conceivably cause a situation where threads are deadlocked. Such a
"thread" command was in pydb CVS up until just before the release. I
removed it because it was likely to cause too many headaches. And you've
confirmed this was probably the right thing to do. If you are issuing bug
requests about having to issue a step in thread debugging (fixed in CVS)
or that "next" in thread debugging sometimes acts like "step", this was
much more serious.

Lastly a comment with respect to wanting features, inexperience in this o=
r
that area and hoping there's a cadre of programmers out there who are jus=
t
waiting for the suggestion on things you want. The best way to make sure
something gets done is to dig in and do it. I often hear, "gee I'd really
like this or that but I really don't know all that much about it." If I
had waited for someone else to improve the Python debugger (or the write =
a
debugger for bash or GNU make or write a cross-platform CD reading
library) it would have never have happened. I suggested the debugger for
GNU a year before I did the work. And prior to undertaking these things
I'd hardly consider myself an expert in them. I'm not sure I would even
now. My exposure to Python is less than a year, and as I mentioned
previously, I really don't use threads or do thread debugging all that
much.

> First of all I want to express my appreciations of efforts that Pydb
> developers spent to bring such a superior alternative to the Pdb debugg=
er.
>
> Second, a little disclaimer. I have a rather insignificant expertise in
> Python development in general and system Python programming in particul=
ar.
> My background in emacs, bdb, ddd and other UNIX/Linux technologies is a=
lso
> minuscule =96 although I have plenty of experience developing multi-thr=
eaded
> application via C++ under Windows. Also my mail represents my own
> day-to-day tactics of tackling variety of debugging issues, which may n=
ot
> be a typical approach for other Python developers.
>
> 1.    My bread-and-butter debugging scenario in multithreaded environme=
nt
> is to debug rather small set of source lines at one time. I am typicall=
y
> set few breakpoints in the code executed in thread of my interest and
> using step and next (or something like that) to go through my sources
> examining value of variables and looking close to code workflow. For th=
at
> scenario I would be definitely interested that step, next, finish and
> return would be conducted ONLY in the context of current thread. To me
> continue statement is bit different. I would allow it to continue
> execution of all threads until a BP hit in any of them. The other appro=
ach
> is to allow only current or specified thread to be continue implicitly
> should pause other threads execution and while it may be technically
> feasible on Python it may not be desirable in most of the cases =96 at =
least
> for me (one may argue to modify your suggesting to use something like
> continue __all__ statement)
> 2.    Sometimes (although not as often as in first scenario) I do like =
to
> look at all or some other thread state (use something like =93info thre=
ad=94
> statement). Typically I would need to do it to understand overall state=
 of
> execution, debugging for possible deadlocks, or understand dynamics of
> threads execution. One can also use this opportunity to move-on on
> debugging code executed in the different thread. If new code of interes=
t
> has no breakpoints yet it often useful to put them there at this time a=
nd
> continue (see my comment above about continue statement) because quite
> often the current top os stack frame of the other thread(s) locate far
> apart from the debugging area. Only in case if it is right near than yo=
ur
> suggestion about next, step with thread=92s name/number would be very
> convenient. One may also suggest to add a =93finish=94 statement to thi=
s list.
> Better yet provide =93finish=94 with additional optional numerical argu=
ment
> which would allow to finish more than one function at the time. One my =
add
> the same argument to =93next=94 statement and even =93step=94 although =
it probably
> will be less useful than finish.
> 3.    I would be interested to setup breakpoints only in particular thr=
ead
> using its name/number via some optional parameters for cases when you h=
ave
> few breakpoints in the code which executed simultaneously by many threa=
d
> but you want to follow only one logical/physical thread. Or may be even
> have command which can modify BP to stick only to one, few or all threa=
ds.
> May be this can be done using condition statement but I am not aware ho=
w.
> 4.    I would be interesting to have a statement which can specify to
> continue until the following line. One can probably do this with
> combination of tbreak and continue but that would be one statement less=
 to
> type. Probably this can be achieved with alias and I need to run more
> experiments with this.
>
>
> And last but not least, I would like to ask the question which may be
> slightly off topic. I would like to examine values via tool-tip if mous=
e
> hover over expression/selection for few seconds,
> set/remove/disable/display breakpoints on the same small vertical grey
> area where current execution triangle cursor is displayed. I would even
> move to appropriate code location if double-clicked on the stack frame.=
 Or
> having split gud-xxx window which would constantly display =93display=94
> values, list of break points and let=92s say list of threads. It probab=
ly
> can be done mostly in LISP and no one would spent an effort but who sai=
d
> that we cannot dream J
>
> Thank you guys.
>
> Len.
>
>
>
> _________________________________________________________________
> Share your special moments by uploading 500 photos per month to Windows
> Live Spaces
> http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=3Dhtt=
p://www.get.live.com/spaces/features-------------------------------------=
------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV_______________________________________________
> Bashdb-pydb mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-pydb
>