Bugzilla – Full Text Bug Listing
| Summary: | Dead lock when debug session starts | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] Target Management | Reporter: | Samuel Wu <samuelwu> | ||||
| Component: | RSE | Assignee: | David McKnight <dmcknigh> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Martin Oberhuber <mober.at+eclipse> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | dmcknigh | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 3.3 M3 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 326712, 327070 | ||||||
| Attachments: |
|
||||||
|
Description
Samuel Wu
Are you trying to debug a program on a different system from the system that contains the files? Otherwise, I'm not sure why there would be an attempt to connect when you're debugging. I tried to reproduce this by debugging a program on one system A with source lookup on a disconnected system B but I didn't hit this. 1. The debuggable application and the source are on two different systems. 2. Disconnect the system and make the breakpoint view visible before the debug seesion is started. That's how we reproduced it. When we replacee the following line
while (contains(cs)){ // wait until the connector service is no longer in the list
with
while (contains(cs) && Display.findDisplay(Thread.currentThread()) == null){ //
wait until the connector service is no longer in the list
in SubSystem, the problem seems to go away
(In reply to comment #2) > 1. The debuggable application and the source are on two different systems. > 2. Disconnect the system and make the breakpoint view visible before the debug > seesion is started. That's how we reproduced it. I tried that but I still can't reproduce the bug you're hitting. Is there something special about the breakpoints in your breakpoint view? (In reply to comment #3) > When we replacee the following line > while (contains(cs)){ // wait until the connector service is no longer in the > list > with > while (contains(cs) && Display.findDisplay(Thread.currentThread()) == null){ // > wait until the connector service is no longer in the list > in SubSystem, the problem seems to go away So, in other words, it works for you if the code is changed to not wait if you're on the main thread. I still would like to be able to reproduce this. Our tester just found another scenario for this same problem. It happened our project tried to resolve a remote filter by RSE. As the password prompt was waiting for the user input, another filter resolving request was sent to RSE. The sourece lookup and breakpoint scenario is just one of the situation. There are at least two more people in my team, not including me, who ran into the same problem. I reproduced it in my runtime workbench. Please let me know if you want to take a look. (In reply to comment #6) > Our tester just found another scenario for this same problem. It happened our > project tried to resolve a remote filter by RSE. As the password prompt was > waiting for the user input, another filter resolving request was sent to RSE. > The sourece lookup and breakpoint scenario is just one of the situation. > > There are at least two more people in my team, not including me, who ran into > the same problem. I reproduced it in my runtime workbench. Please let me know > if you want to take a look. I was able to reproduce it, when I had put the Remote Systems view in the Debug perspective, launched once, disconnected the connection for the source and then launched it again. I also confirmed that the change that checks for the main thread in the wait loop resolves the hang. Does it resolve the hang in the other scenarios your tester hit? yes, both my scenarios are fixed by the check Created attachment 179895 [details]
patch to not wait when on main thread
Samuel, are you okay with this patch?
Thank you for your prompt response, Dave. Both my problems are fixed by the patch. I'll open a patch request for porting it to 3.6.1 I've committed the change to cvs and opened bug 326712 for the backport. This was originally released to TM 3.3 -- I'm going to file a bug for the R3_2_maintenance backport. |