Home » Language IDEs » Java Development Tools (JDT) » Debug perspective source code window(Source code window initially disconnected)
| Debug perspective source code window [message #1814384] |
Tue, 10 September 2019 16:41  |
 Rick Hodgin
Messages: 25
Registered: September 2019 |
Junior Member |
|
|
I apologize if this is the wrong place to post this.
I'm using Eclipse 2019-06 Eclipse IDE for a Java project. It works perfectly for development and I've become a quick avid Eclipse fan (having used other tools previously).
I do have one issue.
When I put an Ctrl+Shift+B breakpoint on a line, it breaks like it should and shows up in the debug perspective as it should, but the source code window won't respond to F6 step, F5 step into, or any other debugging keys until I expand the thread in the Debug pane, click on another function in the call stack, click on the source code that pops up, then click back to the current function in the call stack, then click on the source code window. Then it works like normal.
This happens about 85% of the time. Every now and again it will work. And typically after I go through this call stack cycling effort that first time, it works thereafter for the remainder of the debugging session (for that running process).
I can't figure out what I'm doing wrong. Any help is appreciated.
|
|
| | |
| Re: Debug perspective source code window [message #1814458 is a reply to message #1814430] |
Wed, 11 September 2019 16:57  |
Rick Hodgin
Messages: 25
Registered: September 2019 |
Junior Member |
|
|
Sarika Sinha wrote on Wed, 11 September 2019 11:07Looks similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=540243
Can you please add a reproducible step in the bug.
It's reproducible almost every time in my current project on my home computer. Here are some details of my project:
A 2007 HP Pavillion computer with a quad-core Intel CPU at 2.4 GHz. 8 GB RAM. Windows 7 64-bit. No anti-virus. Direct Ethernet network. A 500 GB SSD. Eclipse build id: 20190614-1200. (Note: I mention all this because it's a slower computer, and it may be a timing issue.)
I have a project called "te.....". It has to packages, "fi....." and "te.....". fi has two .java files. te has 31 java files.
The project initializes a single JFrame with a single JPanel with a single JLabel, all equal to the size of the window it creates. It has the following threads running:
Main(1) [Java Application
te.....Main at localhost:65159
Thread [main]
Thread [Thread-1]
Thread [AWT-EventQueue-0]
Daemon Thread [Java Sound Event Dispatcher]
Daemon Thread [Direct Clip]
(it has 22 of these Direct Clip threads)
Thread [Te.....Thread]
I have Eclipse set to suspend all threads on breakpoint. I set a breakpoint at some point in code after the environment has instantiated and the application is running. I'm in the Debug Perspective.
It suspends and in the Debug pane, all threads are collapsed. I have to find the thread that was suspended, which I usually know anyway, expand the thread, click on the call stack item associated with the source code file + line the breakpoint was on, then click on something higher up on the call stack to bring up that file, then back to the original source file, then click on the source code window.
If I don't do those steps, I can navigate, edit, switch tabs to edit other files, etc. Everything editor-wise works, but it's like the keystrokes for the debug environment are not connected to the editor window until you click away and click back.
The short list:
1) Set a breakpoint, right-click properties set to Suspend VM.
2) Run app and wait for it to hit breakpoint.
3) Try to use F5 or F6. They fail.
4) Find the thread (if all threads are collapsed) and open it.
5) Click on another call stack entry line to bring up a different source file.
6) Click back on the call stack entry associated with the breakpoint.
7) Click on the source file itself in the editor window.
8) Now F5, F6, F7, F8, other keys work.
|
|
|
| Re: Debug perspective source code window [message #1814466 is a reply to message #1814432] |
Wed, 11 September 2019 20:49 |
Rick Hodgin
Messages: 25
Registered: September 2019 |
Junior Member |
|
|
Simeon Andreev wrote on Wed, 11 September 2019 11:25Hi Rick,
are you able to share the code you are debugging? Ideally with a screenshot of your Eclipse IDE before you did any debugging and then at this part of your description:
Quote:but the source code window won't respond to F6 step, F5 step into, or any other debugging keys
What you describe definitely sounds like a bug, so we will need some information to fix it.
Best regards and thanks,
Simeon
It's proprietary code so I cannot. However, would it be possible for me to get the source code for Eclipse and inject code which allows me to hit a special Function Key when it enters that incorrect mode where it's not working (it can snapshot variables of interest, whatever), and then after I hook it back up by going through the several steps to get it working again, then press the key again to do a second snapshot so they can be compared with a diff utility?
[Updated on: Wed, 11 September 2019 20:51] Report message to a moderator |
|
|
| Re: Debug perspective source code window [message #1814521 is a reply to message #1814466] |
Thu, 12 September 2019 15:13 |
Simeon Andreev
Messages: 4
Registered: September 2019 |
Junior Member |
|
|
Could you try debugging your application with breakpoints that suspend only the thread and not the entire JVM? So far I've not worked on bugs that involve VM suspend on breakpoint hit, so it would be a start to know whether this preference is related to the problem.
It would also greatly help if you can try the same steps on a smaller scale and see if you still see the problem. I.e. the following:
Quote:The project initializes a single JFrame with a single JPanel with a single JLabel,
Do you set your breakpoint somewhere in your AWT code?
Unfortunately there is no snapshot option that you can use in this case. The Eclipse debug framework is highly asynchronous, which is usually the cause for not displaying/expanding suspended threads correctly (i.e. the type of problem you are describing). So its important to know which event was processed when; for that, debugging a minimal snippet is usually the best way to find out what the problem is.
It would of course be possible for you to debug the problem yourself, but that would probably be a huge time investment for you. There are some resources on the Debug view here:
https://wiki.eclipse.org/index.php?title=Debug/Developers/Debug_View&modqueued=1
Let me know if you wish to try this yourself.
[Updated on: Thu, 12 September 2019 15:21] Report message to a moderator |
|
|
| Re: Debug perspective source code window [message #1814579 is a reply to message #1814521] |
Fri, 13 September 2019 14:13 |
Rick Hodgin
Messages: 25
Registered: September 2019 |
Junior Member |
|
|
Simeon Andreev wrote on Thu, 12 September 2019 15:13Could you try debugging your application with breakpoints that suspend only the thread and not the entire JVM? So far I've not worked on bugs that involve VM suspend on breakpoint hit, so it would be a start to know whether this preference is related to the problem.
I can. If you have access to TeamViewer, you could get on my machine and witness the effect.
Quote:Do you set your breakpoint somewhere in your AWT code?
At various places. There's nothing specific. At various times it would break when trying to access a null member, or other such bugs. Mostly it's when I hit breakpoints to single-step through code, make changes, drop to frame, and restart the function.
Quote:Unfortunately there is no snapshot option that you can use in this case. The Eclipse debug framework is highly asynchronous, which is usually the cause for not displaying/expanding suspended threads correctly (i.e. the type of problem you are describing). So its important to know which event was processed when; for that, debugging a minimal snippet is usually the best way to find out what the problem is.
I can try to pare it down to something smaller that reproduces the effect. Even right now, it doesn't do it all the time. It's about 85%. And ironically, last night when I was debugging, I had a second project open in Eclipse and it didn't do it at all, even after I closed the second project. It's really sporadic and kind of freaky.
Quote:It would of course be possible for you to debug the problem yourself, but that would probably be a huge time investment for you. There are some resources on the Debug view here:
https://wiki.eclipse.org/index.php?title=Debug/Developers/Debug_View&modqueued=1
Let me know if you wish to try this yourself.
I wouldn't mind doing that, but I'll try other avenues first. TeamViewer works on Linux, Windows, Mac, so if it continues and you want to examine my running instance on my machine, see my settings, etc., we can hook that up if I can't get it to fail reliably on a smaller redacted subset of my code.
I appreciate your help.
|
|
| | | |
| Re: Debug perspective source code window [message #1814697 is a reply to message #1814695] |
Mon, 16 September 2019 17:03 |
Rick Hodgin
Messages: 25
Registered: September 2019 |
Junior Member |
|
|
Simeon Andreev wrote on Mon, 16 September 2019 16:42Rick, if possible please also try working with the setting "Show System Threads" in the Debug view.
You can enable this from the Debug view menu -> Java, see below:
[snip image]
You will see more threads due to this, but at least in the snippet I've created I no longer see the problem with this setting (with about 50 repetitions anyway). So the setting maybe helps in the short run; knowing whether the setting helps will also narrow the potential causes down.
Note that fixing this might take some time, since right now I have no priority for it at work.
I will do so. I'm not at that computer right now.
I tried to affirm what you said about causing a break in the AWT by doing something like passing an invalid value into new Color(). I cannot tell if that's an issue though because I can't do anything there because I don't have the source code.
In addition, I did notice that in many of the cases where it was failing it's being dispatched from a dedicated timer thread which looks at a list of timer events and processes them based on the nanosecond delays for each one. I have a 1x per second timer, 2x timer, 10x timer, 30x timer, and a continuous one used for variable length delays based on various system events.
It seems that the disconnect happens more often there when something is triggered from the timer event rather than from an I/O event-driven block of code like mouse move or keyboard input.
I will try to check on it tonight. If not, it will be tomorrow evening.
[Updated on: Mon, 16 September 2019 17:03] Report message to a moderator |
|
|
| Re: Debug perspective source code window [message #1814984 is a reply to message #1814697] |
Mon, 23 September 2019 16:50 |
Rick Hodgin
Messages: 25
Registered: September 2019 |
Junior Member |
|
|
I've been doing development for several days, and it seems to be completely random. I cannot find anything that explicitly ties it down. It happens sometimes, not always, sometimes on breakpoints, other times when it encounters a null value, etc. Sometimes it is able to keep going with keys like F5-F8, other times not. The only thing I can say is that when it's disconnected, the thread is not open in the debug pane on the left. I have to find the thread, and then click on two source files in the call hierarchy to get it to work, some other file than where it stopped, then the one where it stopped.
I wish I had more information to give you. If anyone devs would like to Team Viewer into my computer and see it in action I can set that up. I'm on EDT and I typically am on that computer on the weekends and weekday evenings.
[Updated on: Mon, 23 September 2019 17:13] Report message to a moderator |
|
| | | | | | | |
| Re: Debug perspective source code window [message #1815054 is a reply to message #1815049] |
Wed, 25 September 2019 03:43 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Yes, this is how the platform team prefers to develop. They use their own latest tools as the development IDE, i.e., the setup installs from the latest 4.14 integration builds. The target platform is also populated from the latest 4.14 Integration builds as well. The API baseline tools are enabled with an API baseline populated from the 4.13 release. All the repos are on the latest master branch. It's easy to pull multiple repositories from the Git Repositories view via multiple selection, so you can update those anytime easily. And via Help -> Perform Setup Tasks... you can update both the installation and target platform to the latest update, i.e., to the most current 4.14 integration build; there's a new at least once per day.
As for finding code, the plug-in spy can be quite helpful to tell you which classes implement what you see in the UI, i.e., Alt-Shift-F1 and Alt-Shift-F2 for menu spy. Also, because you have all the source code, you can use Search -> File... to search for the labels that you see in the UI; these are typically defined in a *.properties file because they are translatable. From that you can determine the property name, and searching for that will find where that thing is used. Also the Call Hierarchy works well, even on static final constants to find where those are used. Then it's useful to set breakpoints in the source of interest, and debug launch the "Runtime Workspace" to see the code in action. It's often useful as well to pause the main thread to see what its doing.
I've not worked on the debug framework itself, so I don't know where specifically to point you at for that. But I always use the above approach when I'm trying to discover how something currently works in some part of the framework that's new to me... And I generally assume that helpful answers will be hard to come by. :-P
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Debug perspective source code window [message #1815095 is a reply to message #1815054] |
Wed, 25 September 2019 12:09 |
Rick Hodgin
Messages: 25
Registered: September 2019 |
Junior Member |
|
|
Ed Merks wrote on Wed, 25 September 2019 03:43As for finding code, the plug-in spy can be quite helpful to tell you which classes implement what you see in the UI, i.e., Alt-Shift-F1 and Alt-Shift-F2 for menu spy. Also, because you have all the source code, you can use Search -> File... to search for the labels that you see in the UI; these are typically defined in a *.properties file because they are translatable. From that you can determine the property name, and searching for that will find where that thing is used. Also the Call Hierarchy works well, even on static final constants to find where those are used. Then it's useful to set breakpoints in the source of interest, and debug launch the "Runtime Workspace" to see the code in action. It's often useful as well to pause the main thread to see what its doing.
I've not worked on the debug framework itself, so I don't know where specifically to point you at for that. But I always use the above approach when I'm trying to discover how something currently works in some part of the framework that's new to me... And I generally assume that helpful answers will be hard to come by. :-P
Understood. And I do appreciate your actually helpful replies. :-)
|
|
| |
Goto Forum:
Current Time: Fri Jan 03 00:34:47 GMT 2025
Powered by FUDForum. Page generated in 0.05467 seconds |
] 
Search
Help
Register
Login
Home
