| Summary: | "Source not found." when debugging remote | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Stefan Cordes <rsc> |
| Component: | Debug | Assignee: | Sarika Sinha <sarika.sinha> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | marcel.bruch, Michael_Rennie, sarika.sinha |
| Version: | 4.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
|
Description
Stefan Cordes
Correction: Since _Luna_ (4.4.0) Attachments are missing. Found a clearer problem description: When a breakpoint is reached via remote debugging and "Edit Source Lookup" is used there, the source does not appear. After disconnecting and connecting again the the VM the source path is used and the source is visible. So workaround: disconnect and re-connect to the remote VM after changing source lookup path. *** Bug 442406 has been marked as a duplicate of this bug. *** The very same issue happens to when debugging JUnit tests in the IDE without going over tcp sockets. FWIW, I've a unit test that executes a class in an x-internal package (OSGI-bundle). (In reply to Marcel Bruch from comment #5) > FWIW, I've a unit test that executes a class in an x-internal package > (OSGI-bundle). Ignore that part. Suddenly, I can step into the code. The only change (I'm aware of) I made was closing a second (completely unrelated) Eclipse instance I had running on the same machine. However, this also seems unrelated because after restarting that second IDE again, I could still step into the source code. (In reply to Marcel Bruch from comment #5) > The very same issue happens to when debugging JUnit tests in the IDE without > going over tcp sockets. > > FWIW, I've a unit test that executes a class in an x-internal package > (OSGI-bundle). The Java debugger always uses socket communication, even for 'local' launches. That said, is there any chance we could get a test project / steps to reproduce the issue? I tried a local and remote debug session and could see source as I stepped, so any more clues would be greatly appreciated. (In reply to Michael Rennie from comment #7) > That said, is there any chance we could get a test project / steps > to reproduce the issue? It's yet not reliably reproducible for me. Here's what I think could make sense. I'll let my IDE run with -Xdebug etc. and will connect to it from another instance as soon as the problem occurs again. Can you give me some pointers in which methods I should set breakpoints and start analyzing myself? (In reply to Marcel Bruch from comment #8) > (In reply to Michael Rennie from comment #7) > > That said, is there any chance we could get a test project / steps > > to reproduce the issue? > > It's yet not reliably reproducible for me. Here's what I think could make > sense. I'll let my IDE run with -Xdebug etc. and will connect to it from > another instance as soon as the problem occurs again. > > Can you give me some pointers in which methods I should set breakpoints and > start analyzing myself? Try these classes: org.eclipse.debug.core.sourcelookup.AbstractSourceLookupParticipant org.eclipse.jdt.launching.sourcelookup.containers.JavaSourceLookupParticipant org.eclipse.debug.internal.ui.sourcelookup.SourceLookupFacility A related bug in source lookup that was recently fixed is bug 437193, perhaps also grab a recent I-build and see if the problem persists. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |