Breakpoints and debugging sessions

[Tree]

Using java and slickedit 13.0.1.0, I have a very strange behavior.

If I'm trying to debug something, when I connect to the debugger, my breakpoints are gone!

Here's the full scenario:
1 find code I want to debug. Insert some breakpoints (debug-toggle-breakpoint, F9 in my config)
2 find a machine to test on, and start the program waiting for a debug connection
3 tell slickedit to connect to said machine (debug-attach, control-F5 in my config)
4 Look at breakpoint list, expecting to see the breakpoints I inserted in step 1.

Now, usually but not always, in step 4, the breakpoints I inserted in step 1 are not present!
This used to work.

So, my question is, what am I doing wrong? Did I change some config setting that broke this?
How can I set breakpoints outside a debugger and then use them in a debugger?
What use is breakpoint management if they are removed when starting an actual debug session?

(Note: this question was sent to support a week ago with no response other than the auto-acknowledgement)

[Dennis]

You breakpoints are tied to your debugging session.  When you start a remote session, you are prompted which session you want to use.  The default is usually a concocted name based on the remote parameters.  If you have set breakpoints in your previous session (by default, your current workspace), then you need to select that session when you attach.

[Tree]

I've never (as far as I can tell) been prompted to select a debugging session under any circumstances.

Could this be a configuration setting somewhere?

[Dennis]

If you do Debug > Start or Debug > Step Into, you will always get the default (workspace) debugging session, so yes, you will not be prompted.  If you start remote debugging the way it was intended "Debug > Attach Debugger > Attach to Remote Process using GDB", you will be prompted.

[Tree]

I always use debug-attach, which I have bound to a key. I believe it is the same as Debug -> Attach Debugger -> Attach to java virtual machine. They behave the same: I am not prompted for a debug session.

[Dennis]

Sorry.  Looking over the code, I see now that we changed the way this behaved since I initially wrote it.  The original design always prompted, now it only prompts if you don't give a program name.  Someone probably complained about us prompting for information that we needed to have...

I suggest that you dock the Debug Sessions toolbar and use it to see what the current session name is and to select the correct session when you set breakpoints.

[Tree]

Ah. Interesting.

That... does something which appears to be internally consistent. I'm surprised that sessions to new hosts don't copy the workspace session, but I guess you can debug locally, too.

I don't like it, though. Picking "where am I going to test" before "what is the functionality I'm testing" will be a big headache. And not being able to switch testing locations with the same context (say, for a different OS) is a major drawback.

Is there a way to turn this off? (Have all sessions use one set of breakpoints)
Or copy from one session to another?

Thanks for your help explaining this!

[Tree]

Resurrecting an old thread with the correct context.

I want to dock the Breakpoints and Debug Sessions together and have them auto-hide. Is this possible? (now in 15.0.1.3)

I can't seem to get it to work. They appear correctly when not hidden on the left hand side of the screen, but clicking the auto hide only hides the breakpoint window. (The breakpoint window without the Debug Session context is, of course, completely useless when not already debugging)

[ScottW, VP of Dev]

The "Debug Sessions" tool window cannot be grouped into a tab group and cannot be auto-hidden. It's rather a lot like the "Current Context" tool window. As they are currently implemented, I wonder if they should be in the toolbar group rather than tool windows. The docking and visibility behaviors are more consistent with the other toolbars than with tool windows. That change wouldn't address your issue, though.

For now, I don't see any way to achieve what you're looking to do.  Sorry.

[Tree]

It would make sense to give direct control of *which* breakpoints you are dealing with to the breakpoints window, then. For use OUTSIDE of a debug session, to assign breakpoints for the *next* debug session.

Or I'm sure there are other ways of solving the fundamental problem of disappearing breakpoints... that's the real issue, of course.