Multiple debuggers
Hi All,
I would like to discuss one of the features a lot of people have been requesting us: multiple debugger instances per project.
Could you share your thoughts and suggestions of how the feature should work from the user's point of view?
Some problems to consider:
1. When you add a line breakpoint, to what process are you targeting it? Should the breakpoint be shared between the processes
currently debugged (the debugger tries to add breakpoint requests to all debuggees). Or if the breakpoint should be set up for only
one process, what's the best way to choose for which one?
2. When you perform such actions like stepping, expression evaluation etc, to what debuggee process are you expecting the actions to
be applied to?
3. When hovering with the mouse over a variable, a tooltip with the value is shown. Provided the class exists in several debuggees,
what value to show?
One of the important things that should be introduced, is a notion of "active debuggee" - the debuggee to which all the actions
described above will be applied (similar to a control currently posessing focus in a GUI form). Then the question arises: what are
the events that make the debuggee "active": explicit selection as "active" by the user or/and hitting the breakpoint in the target
process? More generally, how do you see the "focus changing policy" that won't confuse the user and make him/her "lost in the
debuggers"?
I see only one use-case when multiple debuggers would be useful - client/server applications. But personally I would choose another
approach for debugging: I would set up 2 projects (for client and server) and opened them simultaneously: each project could have
its own debugger and since the project are in different frames, my debugging contexts are well separated. I don't see any problems
in such configuration, but looks like some people have different opinion : please share your thoughts why the suggested approach
soes not suit you and why you find opening multiple debuggers in one project more convenient.
Perhaps you could describe other situations when multiple debuggers would be handy: the use-cases you describe could help us make
the feature really useful (and usable) for those requested it.
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
请先登录再写评论。
Hi Eugene,
>
Another scenario that I have come across several times: Projects that run as a WebApplication and also have classes with main() methods to be invoked (for administrative things like backups, maintenance) - I guess you could call that a server/server configuration.
Regards,
Jens
Eugene Zhuravlev wrote:
I suppose when you have multiple debuggers there would be several tabs
in the debug pane. How about simply making the active tab the active
debugger?
Occasionally when I've run a program in the debugger and found a bug (an
exception or just something wrong in the output), I want to keep that
program running, do something to fix the bug, and then start a parallel
debugger to see whether it was fixed. I want the original program to
keep running in order to compare stack frames, the contents of a GUI
window, or whatever.
Eugene Zhuravlev wrote:
I'd be happy that the default behavior (when I set one) is "all debugged
processes. "
The bkpt properties dialog could be used for a more sophisticated setting
The current debuggee, as you define below.
The current debuggee one, as you define below.
the debug tab may have a control 'make default debuggee' that can be
activated when more than one debugged process is started.
yes, hitting a bkpt should switch the current debuggee.
to avoid the lost feeling, the debug tab may be brought up when the
switch happens.
yes, but also peer2peer and more distributed apps
(clientfrontendbackend processes ....)
But personally I would choose another
main reason: it's annoying to have to define multiple projects.
also having more debug tabs per project gives that nice feeling of
uniformity with 'run' tabs.
Edo
On Thu, 08 May 2003 14:49:10 +0400, Eugene Zhuravlev wrote:
I hit this awhile ago when debugging some code that conversed and talked
over RMI to the other part of the project. As part of the project, the
ant build script built both parts and deployed them into where ever they
ran on my machine.
I set a breakpoint in one code, and was single stepping through the code,
and wasn't aware of which bits where calling into the RMI side ( new
project I joined at work ), what would have been cool, was if I could
single step from the first VM, into the second VM.
I'd see this as setting up a debug run with multiple remote vms to connect
to, and Idea could somehow realize that the step-in was jumping over to
the other vm ( know idea how you'd do that thou ).
In this case - I don't -care- which VM is currently running the process,
just that I've set a breakpoint in "my code". Maybe by default
breakpoints are set for all attached Vms, but under breakpoint settings,
the user can further specify which VM to use/watch.
Visually showing which VM the code is running could be nice, either a
different colour background, or different colour in the margin...
Mark
--
...turn to the light - don't be frightened by the shadows it creates,
...turn to the light - turning away could be a terrible mistake
...dream theater - the great debate
What do you think could be done to reduce or eliminate this annoyance?
Things I'm thinking of are 'cloning' a current project, even better if
clones could be kept up to date with each other as libraries are added
etc... Maybe the new modules stuff will help here?
N.
>
>
>
On Thu, 08 May 2003 12:32:03 +0100, Nathan Brown wrote:
The new project groups which Eugene has mentioned being in the works could
come into play here.... multiple sub projects, each having their own
debug instances settings....
--
...turn to the light - don't be frightened by the shadows it creates,
...turn to the light - turning away could be a terrible mistake
...dream theater - the great debate
I don't think this is a justification for the complexity of adding multiple debug sessions.
Perhaps I can suggestion an alternative:
What if we could create a temporary project for our current project configuration. Another IDEA window would come up
and we would be able to set breakpoints, run, create a "single" instance of a debugger, and so forth.
Ideally, these would be "views" on the same underlying parsetree for resource purposes. So they would be light weight.
You could create as many as you wanted. All of the same conventions used to debug a single debug'd process would apply (no worry about the issues Eugene raised).
The only possible exception to this is that you could make breakpoint selection either shared , or specific to the temporary project. I would be inclined to make it specific to the project, but a way of "propagating the breakpoint among all temporary projects would be useful.
Comments?
Mike
Eugene Zhuravlev wrote:
In practice I only want the break point on the current process. This is
because many times the multiples processes are sharing code at some
level and the problem I'm trying to solve in one process tends to be
unique to that context.
I would expect a seperate debug panel for each running process (similar
to the run panels). Thus the context is implicit in the panel in which
you are working, ie, the process of the current panel.
Similar to above, use the context of the debug panel that is visible.
What if no debug panel is visible? Good question. Maybe these kinds of
debugging features need not be available when a debug panel is not visible.
Hmm, now that I think some more, since the debug panels are floatable,
"current" does not have as strong a meaning as with a purely tabbed
interface. If I recall from jbuilder (I can fire it up check if need be)
you can select the "current" debug process/panel.
Another alternative, again similar to jbuilder, is to allow for opening
a new top level window on the current project. This is different from
opening a second project in a new top-window, in that the same project
is opened, but the working context is unique to that window. Think of
the workspace plugin except the context of the workspace is attached to
the top-window and there can mulitple open workspaces.
Client/server app is indeed the use-case that motiviated my request for
multiple debuggers. But in our case it is client/serverS. We generate
a dozen or more servers from the same project (and the same jar file).
The servers use the same core framework, infrustructure, and domain
objects, but represent various aspects of a workflow. A workflow in the
business sense, but also to support horizontal load balancing,
scalability, and high availability (facilitated by the jms).
Where we could create a dozen projects (one for the infrustructure, and
one each for ever server), that would simply not be a productive way to
operate. Especially with the current idea project model (we would have
to update all server projects each time the infrastructure add a new jar
for example). It also is not productive in that we like to have all the
code available all the time to ensure that refactorings are fully
applied across the system, and so that we can run /all/ unit tests
before we deliver.
Hope some of this helps to motive the desire.
-bk
I think that use cases needing two debugger instances simultaneously for the same project are very rare. Therefore this feature shouldn't have any impact on 'normal' debugging as it is now.
I agree with Eugene that the one-debugger-per-project approach should be sufficient in any situation.
The idea of a temporary copy of a project (or some read-only view of an already opened project) seems rather convenient.
What I would avoid in any case is having multiple tabs in the debugging window, changing the 'active' debuggee by selecting another tab. This complexity would do more harm than good for my taste.
all for it! it keeps things simple. also when a non-active debuger hits a
breakpoint, it's tab should somehow signal that (blinking?).
Should the breakpoint be shared between the processes
debuggees). Or if the breakpoint should be set up for only
it will be nice to be able to set global breakpoints as well as per
debug-target.
to what debuggee process are you expecting the actions to
"active debugee" concept will work well
is shown. Provided the class exists in several debuggees,
the one for the active debugee.
"active debuggee" - the debuggee to which all the actions
focus in a GUI form). Then the question arises: what are
by the user or/and hitting the breakpoint in the target
won't confuse the user and make him/her "lost in the
having the active tab in the debug window be the active debugee, as Jonas
has suggeseted in another post, is a very good idea. it solves the "lost in
the debuggers" problem.
hitting a breakpoint in the target window could simply make a different tab
flashing but should not make it active, since i could be stepping at the
moment. which brings me to another point, what about extending the debugger
to allow stopping at multiple breakpoints in a single debugee? i really miss
this for multithreaded debugging.
client/server applications. But personally I would choose another
and opened them simultaneously: each project could have
debugging contexts are well separated. I don't see any problems
please share your thoughts why the suggested approach
project more convenient.
be handy: the use-cases you describe could help us make
1. often there is the server/server configuration, when debugging clusters
for example
2. the convenience (which might as well be first). currently i'm using
multiple run targets and a single debug since i can't really open one
project twice; and even if i could, why would i need to see my sources
twice, it's simply another debugger tab, same as run - simple and
consistent.
3. with the introduction of modules/subprojects, i would like to be able to
debug all subprojects (being test clients, or different out of process
components) in one place.
Over all this sounds like a lot of complexity for the problems it solves. But on
the other-hand, IDEA seems like the first environment I've used where I would
keep a client and server together in one project (after all, they are tightly
coupled and share a lot of code/setup). And in that situation, multiple
debuggers is a must.
I agree, I used to get mighty confused in JBuilder (version 5) where there is a
current project selector but also multiple debug tabs down the bottom. I always
think the current debug tab is the active debugger, but in fact it's actually
the project chosen in the project selector. It's intuitive to have it with the
debugger tabs - since they are the visual manifestation of the debugging process.
But even still, this is not IMHO a "good" solution.
Well, we thought about this. Actually the solution looks like the one I proposed (with 2 simultaneously opened projects), but
instead of several opened frames there are several debugger windows. Together with the fact, that editors are now shared between
these debugger windows, the solution adds more mess than value.
What about the following model:
there's still one debugger window representing "Debugger" as a tool rather than a debuggee process. There's a feature in the
debugger that allows it to connect to multiple processes. In the UI there will be additional "Process" node in the Threads View (the
view probably should be renamed?) and the view contents will look like this:
Process "Client"
---Thread "ClientMain"
--- stackframe1
-- ........
---stackframe N
Process "Server"
---Thread "ServerMain"
--- stackframe1
-- ........
---stackframe N
Instead of "active" debugger there will be a notion of "active process" - the process currently selected.
That way we avoid debugger window clutter.
But since you've already made changes? the text in the editor doesn't match classes that are executed in the "old" debugger.
Perhaps here the "hotswap" feature will be of more help?
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
"Eugene Zhuravlev" <jeka@intellij.com> wrote in message
news:b9dcn6$2t9$1@is.intellij.net...
client/server applications. But personally I would choose another
and opened them simultaneously: each project could have
debugging contexts are well separated. I don't see any problems
please share your thoughts why the suggested approach
project more convenient.
be handy: the use-cases you describe could help us make
>
I use two debugging sessions for testing EJB's in JBoss. Similar to your
preference, I have two different projects with two different debuggers, one
for client in local JVM, one for server in remote JVM. It is not
particularly awkward to switch between the two, but then I am used to being
retrained by (un)available features in software to do things less
efficiently. :)
Since the swap between debuggers does not occur often in my case (client
makes a request, then I spend most of the time watching the EJB handle it),
I tend to agree with you -- just set up two projects and be done with it. I
think there are more important things for IntelliJ to be working on --
features that give us more bang for your buck (or, in Russia, more report
for your ruble.)
-Dave
Just about every project I've been on has had several entry points, and I've always missed the convenience of being able to debug multiple processes at a time. I have lots of little test classes with main methods, and I would like to be able to debug them at the same time. Creating a new project seems like a lot of trouble to go to for that, and is memory and disk intensive.
I'm a little bewildered at how complicated everyone seems to feel this is. Hasn't JBuilder does this for ages? Aren't the solutions Eugene proposes fairly straight foward and intuitive? Where's the complexity?
As for the questions posed, I'd go with what most of the others have suggested:
a) breakpoints apply to all debug sessions. breakpoints go with the code, not with the debug session.
b) establish an "active" session, determined either by which session has focus/had focus last, or by manual selection, and indicated by an icon on the debug tab/window. "active" determines which variables show up in the popups, which vm to evaluate expressions in, etc.
Ok, then another question. Currently breakpoint's icon reflects its state. What if the breakpoint is valid for one process and
invalid for another? What icon should the breakpoint have in this situation?
I would argue with this. How often do you set up a project? The operation is done only once when you set up your environment and
then you just use it.
As for the resemblance with the run tabs - yes, it looks similar and uniform, but it also adds additional problems like "to what
debuggee should I attribute the value shown in the tooltip". The difference is that Run's state (the contents of console and
possible actons with the runned process) is well encapsulated in the Run tab, whereas with the "Debug" the debugger's state is also
present in the editor (breakpoints, tooltips, step actions). Since editors are shared between debuggers, their state is partially
messed, which is not good. The configuration I mentioned in the initial post, solves the problem of debugging multiple processes.
The solution being discussed solves the problem, but also adds additional ones.
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
This will work, but does it provide a more operable solution then multiple workspaces?
When multiple debuggers (even with a single debugging tab exist within a single workspace, the assumption is that an individual will have a single set of Editor windows open to service breakpoints in multiple processes.
This seems flawed. It would seem much more reasonable that I would have a set of editor tabs open that relate to those classes specific for my debugged process.
So for each process, I have a unique set of editor tabs, Watches, breakpoints, etc. (in other words...something that looks like a project).
Those of you that disagree with this position, it would be useful to understand the use cases under which such a scenario would not work.
Mike
Are the views read-only or they allow modifications to their contents?
And it looks like the views duplicate the functionality of the editor - is there any difference between them?
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
Eugene Zhuravlev wrote:
this is like the view in Eclipse and I like it.
still, it is not fully consistent with the run view - I think I prefer
the multiple tabs like run.
Eclipse is slightly better in consistency here. there is one single
console window and a drop down list for all launched apps.
BTW its junit integration appears to me to allow just one junit runner
at any one time.
Edo
>
will have a single set of Editor windows open to service breakpoints in multiple processes.
>
specific for my debugged process.
>
project).
>
not work.
>
I see your point and find it reasonable. What you are suggesting looks like "ability to open several frames per project", or even
better, workspaces. This issue deserves a separate thread, because it affects not only debugger but the whole window management
philosophy of the application.
I too have a lot of little mains, yet, I don't debug more then one at a time. Only when we have client/server Inter Process Communication do I launch more than one debugger at a time.
I disagree. I would expect that breakpoints go with the debugger, not the code. Right now I will often set many breakpoints while working on a probblem, get distracted, go work on something else, set more break points, and find my code stopping at unexpected points. How many of you have a hundred disabled breakpoints in your breakpoint list right now? (from past / concurrent bugs).
Mike
I guess I don't set that many break points so I don't run into that.
I saw one suggestion amounting to only breaking in the current active session, but I think that's a bad idea, since you may well be debugging a client and server and want to catch a particular interaction where the client and server should break at almost the same time.
How about this? Grouping breakpoints. By default, all breakpoints go in a global group, but can be copied to other groups. So a group is defined as some subset of the total pool of define breakpoints. Each group (including the global group of all breakpoints) can be activated/deactivated for a particular debug session. By default, a session starts out with the global group, or with a default group selection. A simple gui for selecteing groups might be radio buttons for selecting "include" or "exclude", and a checkbox list of all defined groups (with a window on the side to preview breakpoints contained in the selected group).
This is actually a feature I've missed even in a single session, as I often use different sets of debug points for different bugs, and have wished I could save a group of breakpoints for later use.
This would provide the best of both worlds I think. Default behavior would associate all breakpoints with all debug sessions, which is what some of us would intuitively expect, but offers the ability to associate breakpoints with sessions if you wish. And adds the benefits of better breakpoint organization, and more convenient activation/deactivation of breakpoints.
Oh, and in the editor gutter, to display whether a breakpoint is active or not, either only show the breakpoints state in the currently active debugger, or show three states:
full: active in all debugger sessions/default breakpoint config
empty: disabled in all debugger sessions/default breakpoint config
half: active in some, disabled in some debugger sessions/default breakpoint config
This gets a bit hairy: more information vs less complexity. I would probably go with displaying the breakpoint's status within the active debugger session.
Agreed. This is a bad idea. Defeats the point of having multiple debuggers.
This is a great idea. If you don't mind, you should create a feature request on this independent of the multiple debugger thing.
Mike
1.
2.
3.
4.
Multiple debuggers/tabs in one panel seems prone to a sea of complications.
As suggested before, I would much rather go with a clone of the main project
frame.
Having two main frame would have several advanages:
1. The active debugge is the one on the current frame. Breakpints should be
active only on the current frame, with an option to activate a breakpoint in
all/some? of the other frames/debuggers.
2. Same as 1.
3. Same as 1.
And more:
-> If two debug sessions are stopped at different points the code at the
breakpoint/stack in the two sessions can be seen/compared without trouble.
-> It can be integrated with sub-projects and the Workspace plugin.
-> ?
be handy: the use-cases you describe could help us make
With different startup/config/use parameters, every app can benefit from
multiple debugging sessions, and compare what happens in each session.
Client/Server apps benefit also by comparing what happens when clients
connect to different servers: a database client app launched agains two
different database servers for example.
I think that the complexity of multiple debugger tabs is being overestimated. I just don't see why it's so terribly complicated. The only issues I see are with the "active" session notion, and I think reasonable, simple solutions have been proposed. So why does this still seem so complex?
Russell Egan wrote:
I agree. I used multiple debugger tabs in jbuilder for over a year and
never had any confusion. But then jbuilder /also/ has the ability to
open new workspaces.
I think it would be confusing to have different debug tabs since the debugging context is not encapsulated within the tab. I'd rather prefer to have the ability to open the same project multiple times and be able to choose a debug configuration (which is a good thing even with a single process/debugger). Debug configuration (or debug context if you prefer) is an extention of a run configuration and allows you to define a local set of breakpoints, watches etc. All elements of the configuration (i.e. breakpoints for example) can be configured to be local to configuration, shared across all configurations (global) or shared between certan configurations via a simple list of check boxes like
It would be just great if I can activate certain debug confugurations on some conditions like hitting a specific breakpoint or if some condition becomes true. (I've already posted somewhat similar request for context sensitive watch sets. This is an extention of the same idea). Another good thing is to be able to associate some visual details (colors, fonts, icons) with each configuration. In this case if some configuration pops up I'll immediately notice the change (gee, my background color has changed!)
Now, If I need to debug multiple processes I'd open my project multiple times, choose defferent debug configs in each frame and enjoy the show. Hitting a breakpoint by a process can bring the correspondent frame on top (this must be a configurable option) or make title bar flash or something else. You can have a little status bar on top of all other frames with ability to jump into desired frame with one click.
Then you can extend this basic debugging environment in any way you want including seamless stepping between different JVMs. This approach can also work with different projects in the exactly same way as with a single project.
P.S. Generally it seems not a very good idea to force to create different projects, espesially artificial ones. In fact, the tendency is the opposite. I tend to include more and more (even not directly related) stuff into my workspace (read project). Since the code gets more and more reused it's a good way to keep old projects up-to-date (i.e. all refactorings would automatically apply to old projects as well). Surprisengly, I found myself doing this more and more over time. This is, by the way, a completely new level of development. You don't deal with just today's needs and trends, you can have all your history, inventions, implemented ideas (let's say for the past 10 years), experimental stuff and even somebodyelse's open source code right at your fingertips. Combined with global refactoring and code analysing tools it yields a great power. May be you should think about making it another great selling point for IDEA.
--Oleg
Oleg Danilov wrote:
Good point.
I must say, that before idea prevented the launching of multiple
instances, that indirectly supported multiple debug sessions. It was
only late in Aroura eap that the limitation of only one idea process was
enacted. Of course, with that approach, you had to be careful not to
change the project settings, else last closed will blow away other
instances.
On Thu, 08 May 2003 19:33:18 -0500, Barry Kaplan wrote:
What actually was the reason for limiting Idea to only once instance?
Licensing issues ( I had thought of this, with exported X sessions on
*nix ), but one could still limit multi instances, but only to say the
same display/monitor. Mmm.
--
...turn to the light - don't be frightened by the shadows it creates,
...turn to the light - turning away could be a terrible mistake
...dream theater - the great debate