| Summary: | RhinoRemote debugger can not find the thread because it's too quick and it's finished before the RhinoRequest arrives. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] JSDT | Reporter: | lex78 | ||||||
| Component: | Debug | Assignee: | Victor Rubezhny <vrubezhny> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Victor Rubezhny <vrubezhny> | ||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | amcconnell, arhipov, philip, thatnitind, vrubezhny | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | 3.8 M6 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=363571 https://git.eclipse.org/r/63683 https://git.eclipse.org/c/jsdt/webtools.jsdt.git/commit/?id=3dce316bcd8c3f2ef354483a933b2484b1c77fab |
||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Created attachment 206839 [details]
Trace log
I also am running into this issue trying to use the remote Rhino debugger. It causes a problem because when it occurs, it causes any currently paused scripts to resume (technical details below). Sequence of events: Script 1 begins debugging on Thread 1 and hits a breakpoint, is currently suspended on the server and paused in the client. On Thread 2, my server code enters and exits a Context without running a script. A Thread 2 enter and Thread 2 exit event are triggered. The client handles the Thread 2 enter event and issues a thread request for Thread 2. Thread 2 no longer exists on the server, so a "not found" response is issued. Client sends a resume event with no thread id. Server issues a resume against all current script threads (causing Script 1 to resume and exit debugging). Specific code: In EventQueueImpl, in method remove(), the if clause for handling a THREAD + ENTER event runs. It calls vm.getThread(). VirtualMachineImpl.getThread() checks if it already knows about the thread. If not, it calls createThreadReference(). createThreadReference() issues a THREAD request to the server. The server responds with "not found" since the thread/context have exited on its side. createThreadReference() thus returns null, so getThread() does as well. EventQueueImpl.remove() thus puts nothing in the EventSetImpl object 'eventSet', so at the bottom of the method it enters the if (eventSet.isEmpty()) block. EventSetImpl.resume() has no thread reference so it enters the if clause. VirtualMachineImpl.resume() issues a CONTINUE request with no thread id to the server. On the server side, RequestHandler.handleContinueRequest() runs and finds no threadId in the request, and so issues a resumeAll() call on the debugger. Created attachment 259033 [details]
Stops the client from resuming all threads when the client cant find the thread ID
New Gerrit change created: https://git.eclipse.org/r/63683 Gerrit change https://git.eclipse.org/r/63683 was merged to [master]. Commit: http://git.eclipse.org/c/jsdt/webtools.jsdt.git/commit/?id=3dce316bcd8c3f2ef354483a933b2484b1c77fab *** Bug 386211 has been marked as a duplicate of this bug. *** |
Build Identifier: 20110916-0149 I try to debug remote org.mozilla.javascript.Script executions on a system where multiple Script objects are initialised and when a certain event happens I create a new Scriptable scope and I execute the same Script object. In my code I execute this section only once when the system starts. debugListener = new org.eclipse.wst.jsdt.debug.rhino.debugger.RhinoDebugger("transport=socket,suspend=y,address=9888,trace=true"); Context.enter().getFactory().addListener(debugListener); Context.exit(); debugListener.start(); I submitted a bug about the source is not downloaded to External JavaScript Source folder (Bug 363571) but I saved the source code first and then I try to debug it by putting a breakpoint at the first line. I attached trace logs of multiple executions where the RhinoRequest finds the thread only occasionally. If I add a breakpoint to the script then it stops there every time so I assume there is no bug but there may be some event that may be triggered by this so I thought I report this case too. Reproducible: Sometimes Steps to Reproduce: 1. Detailed steps in the attached file.