Community
Participate
Working Groups
Overview: "Debug with remote application" fails with J2ME Wireless Toolkit (WTK) Emulator as remote VM. Steps to reproduce: - Get WTK 1.0.3 for Windows (http://java.sun.com/products/j2mewtoolkit/download.html) - Install the WTK, verfify installation by executing the following cmd in the WTK\bin dir: emulator -Xdevice:DefaultGrayPhone -classpath ..\apps\demos\classes;..\lib\midpapi.zip example.manyballs.ManyBalls - execute the follwing cmd: emulator -Xdebug -Xdevice:DefaultGrayPhone -classpath ..\apps\demos\classes;..\lib\midpapi.zip -Xrunjdwp:transport=dt_socket,address=2801,server=y example.manyballs.ManyBalls - Within Eclipse use "Debug with remote Java app" localhost/2801/allow termination Expected result: The emulator should run the application. (This does work with Forte f. Java 3.0 CE) Actual result: Emulator does not run the application. One can pause the emulator thread, which results in exceptions being written to the log. It seems that some class information isn´t correctly read from the referenced classfiles in WTK\lib\midapi.zip (snippet from .metadate\.log: 4 org.eclipse.jdt.launching 4 Invalid path: java/io/k:/ws/toolkit/1/0/3-fcs/kvm/api/src/java/io/OutputStreamWriter.java. Java Model Exception: Java Model Status [Invalid path: java/io/k:/ws/toolkit/1/0/3-fcs/kvm/api/src/java/io/OutputStreamWriter.java.] at org.eclipse.core.runtime.CoreException.<init>(CoreException.java:30) The basic communication with the WTK emulator seems to work, it is at least possible to terminate the emulator from within Eclipse. Eclipse version 20020321 on Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cn130-20010207 (JIT enabled: jitc) Chris
Is this still a problem with the latest integration build (200204011)? It would be a great help if you could let us know.
Created attachment 594 [details] Eclipse logfile
Yes, it appears as if the "source name" debug attribute in the class files is fully qualified - an absolute path, including a device (drive). For example: k:/ws/toolkit/1/0/3-fcs/kvm/api/src/java/io/OutputStreamWriter.java. According to the spec, the debug attribute should be a simple source name such as "OutputStreamWriter.java". Thus, we are not able to locate the source.
Seems to be Sun´s problem, not yours. On the other hand, Forte for Java and JBuilder can be used with the Wireless Toolkit, it would be nice if you get Eclipse to work with the WTK as well...
Fixed in JavaSourceLocator. If the debug attribute contains the File.pathSeperatorChar, I strip off the prefix.
Please verify (Darin S).
Created attachment 811 [details] .metadata/.log and 3 screenshots
Still doesn´t work (tested against 20020510) Snippet from .metadata/.log: !ENTRY org.eclipse.jdt.launching 4 4 Tue May 14 09:50:36 GMT+02:00 2002 !MESSAGE Invalid path: k:/ws/toolkit/1/0/3-fcs/kvm/api/src/java/io/OutputStreamWriter.java. !STACK Java Model Exception: Java Model Status [Invalid path: k:/ws/toolkit/1/0/3-fcs/kvm/api/src/java/io/OutputStreamWriter.java.] The garbage in front of the path is stripped now (used to be: "java/io/k:/ws/toolkit/.../OutputStreamWriter.java."), but the full qualified absolute path is still used. Please see the log in attachment 811 [details], there is another error before the "Invalid path" which might be the initial cause for the failure. The screenshots in the attachment were taken in this order: debug1=before suspending the thread debug2=the dialog that comes up when suspending the thread debug3=the debug window after closing the dialog
Was not fixed for 20020510...fixed date is 20020513. Did you pull down the latest from the head stream for your testing?
Sorry, my mistake. I´ll try to compile your 20020513 code and test against that.
No problem.
Verified.
Christian, Have you tried the 20020514 build? With the patches announced on eclipse.dev the build seems to function OK.
I tried with 20020514 and 20020515, your fix doesn´t seem to be in those builds. Where do I find the patches? I noticed binaries on the dev core pages, but couldn´t find any on the dev debug pages (As mentioned before, I was having problems recompiling myself, so a compiled launching.jar would be required).
Reopenning
This fix did not make it into either of the mentioned builds. Please wait for the M6 build.
Marking as fixed, to be verified.
The fix for this is in the 20020519 build. Please re-open if a problem, marking as verified.
Created attachment 908 [details] .metadata\.log
I have tested against 20020520 (Win32 Runtime and JDT downloads) and still see the full qualified path in the .log, see attachment #908 [details]. (Just an unqualified guess: Could this be a similar problem in jdt.debug.ui.JavaUISourceLocator ?)
The Java UI source locator just delegates to the non-UI source locator.
When debugging with J2ME Wireless Toolkit(WTK) Emulator using Eclipse-M6, I met the same problem just like above, the application which running on the emulator was blocked. But when I use bugseeker2 to debug, there's no problem. So I try to capture the JDWP package and analyse the reason. Finally I found that when the Eclipse send ClassPrepare Request, it set suspendPolicy EVENT_THREAD and cause one thread suspended, it is just the reason that application was blocked. After I fix KVM Debug Proxy(kdp) of the emulator to set all suspendPolicy of ClassPrepare Request NONE, the application run sucessfully. But I found another problem that Eclipse just get the info of kvm_main thread, so I can't suspend another thread of the application. I don't know how to resolve it.
I do not understand the problem mentioned above "Additional Comments From Vickie Yang 2002-05-23 22:38". If this is new (different) bug, please open a new bug report.
IMHO, that comment refers to the fact that *remote debugging with Sun J2ME Wireless Toolkit fails* and provides some more insights. Your source locator fix did probably resolve only the problem with malformed .class files in the J2ME WTK distribution. But as I have mentioned before, the full qualified path returned by JavaSourceLocator might not have been the initial cause for not being able to do remote debugging. Perhaps this bug needs to be subdivided into different tasks: - source locator - fix for "org.eclipse.debug.core.DebugException[5010]: com.sun.jdi.InternalException: Got error code in reply: 41" - Vickie´s observations Appreciating your work!(just some padding on the back during freeze ;) chris
Just wondering if anyone has tried build 20020620, to see what (if any) the latest problems are with J2ME? At this point Eclipse is frozen for 2.0, so I will mark this bug as deferred.
Sorry, still does not work in 20020620. The .log entries haven´t changed at all.
Our ClassPrepareRequests are created with a suspend policy of SUSPEND_THREAD so that we can install breakpoints in a class as soon as it's loaded. A suspend policy of SUSPEND_NONE will certainly introduce a timing bug whereby breakpoints will be missed if they are in a location that is executed shortly after the class is loaded.
So you mean that this is a bug of kvm ?
Vickie, in your comment above you mentioned setting the suspend policy of our ClassPrepareRequests to SUSPEND_NONE. I'm just explaining why we actually need a suspend policy of SUSPEND_THREAD. I'm not sure I entirely understand your comment, though. You said, "After I fix KVM Debug Proxy(kdp) of the emulator to set all suspendPolicy of ClassPrepare Request NONE, the application run sucessfully." Are you saying that you actually hacked the KVM Debug Proxy somehow or that you changed Eclipse to set the suspend policy of ClassPrepareRequests to SUSPEND_NONE? You went on to say, "But I found another problem that Eclipse just get the info of kvm_main thread, so I can't suspend another thread of the application." I understand this to mean that when Eclipse sends the JDWP request asking the VM for threads, the VM only returns a single thread. Is this correct? Also, are you certain that more than one thread has been created at this point?
Vickie: I wouldn´t consider it a bug in KVM (WTK). Other debuggers( Forte f. Java, JDB) can be used with the WTK. OTI: I still see this error: "org.eclipse.debug.core.DebugException[5010]: com.sun.jdi.InternalException: Got error code in reply: 41" (same as in my previous attachments) Does this indicate a bug in the jdi implementation? How about using JDB as the lowest common denominator and comparing the behavior of Eclipse against it (see http://wireless.java.sun.com/midp/questions/jdb/)?
When sending Class prepare event the KVM doesn't handle the suspend policy properly. It can send several event before really stopping. So eclipse doesn't resume the thread enought time. Another problem in the KVM : Methods ID in the KVM are taken from class files (because KDP, the debug proxy, and the kvm need to have the same reference index), so the first method in class file will have the id 0 ... But it seems that id 0 is reserved to obsolete method. So you can't breakpoint in this method. (does it work in Forte ?) You need to modify KVM & KDP to correct this. (method index must start at 1). I'm experimenting with the KVM version 1.0.3 here, but I can't recompile the kvm with the same settings that sun. The KVM at start create only one thread with your "main". And simulate a thread group.
Christian, the fact that you see an error with the Eclipse debuggers that other debuggers don't expose doesn't imply that the problem is in Eclipse. We've seen a few instances of these problems where other debuggers work for a particular problem, but Eclipse causes problems. It often turns out that our debugger is simply doing more than others and thus exposes VM bugs that other debuggers don't encounter. Error code 41 is the JDWP error code for "NOT_FOUND - Desired element not found." This is an error code sent to the debugger by the VM. It sounds like we're making a query about a non-existant item, but this doesn't really tell us where the problem is. Are we holding on to an expired handle or is the VM "lying to us" (we've seen this many times as well)?
Jarred, consider me a "user" of Eclipse, so it looks like a bug to me, because other IDE´s don´t exhibit this "error". As a developer, your point of view makes perfect sense to me, but it doesn´t solve the problem of not being able to use Eclipse to debug against WTK emulators :-( I checked against WTK 1.04, same problem. Would it be somehow possible to emulate the "faulty" JDB behavior? (After you guys have come up with such a greate product, I sure wish I could contribute with more qualified suggestions, but I certainly lack JDWP experience)
I finally got a copy of the J2ME WTK and it looks like our bug. We create a ClassPrepareRequest for java.lang.Error for our "Suspend on compilation errors" feature. The ClassPrepareEvent comes to us with a ThreadID of 0, which, according to JDWP spec, means null. We've previously assumed that an event could never come from a "null" thread. However, closer inspection of the JDWP spec yielded the following on the topic of the threadID field in a ClassPrepareEvent: "Preparing thread. In rare cases, this event may occur in a debugger system thread within the target VM. Debugger threads take precautions to prevent these events, but they cannot be avoided under some conditions, especially for some subclasses of java.lang.Error. If the event was generated by a debugger system thread, the value returned by this method is null, and if the requested suspend policy for the event was EVENT_THREAD all threads will be suspended instead, and the composite event's suspend policy will reflect this change." This describes the situation here exactly.
Jared, Thank you for your hard work! Through going deep into Eclipse, KVM and KDP (actually WTK equals KVM + MIDP + KDP), finally I considered that it's fault of WTK which base on Sun's kvm reference implement. To solve these problems, we should hack KVM and KDP to make our own emulator or request Sun correcting WTK. And Eclipse debugger should follow JVM spec. Eclipse is a great IDE, I like it.
I got it to behave better by adding code to handle event with null threads. The next problem that came up was an UnsupportedOperationException that was thrown in response to ThreadStartEvents from the VM. This was happening because our code for handling the ThreadStartEvent (in JDIDebugTarget) asks thread.isCollected() before creating a JDIThread object for the VM thread. The WTK responds to the ObjectReference.isCollected query with "OPERATION_NOT_SUPPORTED". However, this is *not* an optional operation. According to spec, the VM must be able to answer this query. This bug is the reason that only one thread shows up in the debug view. If I add a catch for UnsupportedOperationException around our thread.isCollected() call, two more threads show up in the debug view. Suspending either of these threads actually causes the emulated program to suspend (suspending the "main" thread doesn't). All in all, the WTK seems flaky at best. While debugging, it was dumping errors to the system console. These errors make for a generally weak debugging experience. We should definitely fix our null thread handling. That's our bug. It's unclear that we should actually release the code for handling the UnsupportedOperationException as this really seems to be a VM bug. Then again, this wouldn't be the first code in Eclipse that's written specifically to deal with a VM bug.
Jared, you´d certainly do me and other developers a great favor if you added code to catch the UnsupportedOperationException (and whatever else might creep up). A simple switch in the .options to enable it would do. I´m afraid that handing over the responsibility to Sun won´t help for two reasons: - Eclipse is THE competitor to Netbeans/Forte/Sun ONE Studio (wonder how it is called next week ;), so why support it? - Device vendors that license the KVM from Sun reproduce the bug in their device specific emulators. It´s probably futile to ask them to fix the bug in their code. Chris P.S: Sorry for misspelling your name in my prev. posting
Christian, I'm inclined to release the UnsupportedOperationException workaround. I've also found another bug that was brought up here. Upon reexamining our Method.isObsolete() implementation, I realized that we've got a bug there. Our implementation just returns methodID == 0. However, for pre-JDWP 1.4 VMs, this doesn't make sense. Method.isObsolete() should always return false for JDWP < 1.4.
Reopening for more work.
Ok. So now I can see more threads and I can get info for methods with ID 0. However, the VM is returning an error when we ask for line info for some stack frames, resulting in a stack frame that just says "<not responding>". This is really our problem. JDIModelPresentation.getText catches DebugException and returns "<not responding>". The methods that it delegates to (in this case, getStackFrameText) just throw DebugException. The end result is that if we get an exception when asking about any single piece of data for a stack frame, we don't give the user any information. We can do better. I've fixed JDIModelPresentation.getStackFrameText() to wrapper each query (declaring type, receiving type, method name, line number, etc.) in a try/catch. This way, we can just say "<unknown x>" if an exception occurs retrieving any information x. This is a big win. Instead of seeing "<not responding>" on the stack frame, I now get "com.sun.kvem.midp.lcdui.EmulEventHandler$EventLoop(java.lang.Object).getClass()<unknown line number>" The lack of robustness in the KVM debug proxy is really very useful for finding assumptions in our debugger. :) We need more "junky" VMs for testing.
Created the following bug reports for the problems discovered here: Bug 21305 - Debug element rendering can be more robust Bug 21306 - JDI client does not tolerate null thread from events Bug 21308 - Method.isObsolete() broken for method ID 0 on JDK < 1.4 For the purposes of closing this bug report, please verify the workarounds I added in ObjectReferenceImpl and ReferenceTypeImpl.
Please verify.
I have tried the last change but is doesn't seem to always work here. Also it's the first time I modify an eclipse plugins. Here is what I have done. - Imported into eclipse the org.eclipse.jdt.debug_2.0.0 plugin. - Applied by hand the last CVS (using the CVS web interface because I can't access CVS server directly) change to the source. - Used the "Create Jar" command on the plugin.xml file. - Replaced the debug plugin jar file with the new compiled version. Is it the best way ? I use the ManyBalls WTK104 example. * When I place a breakpoint in SmallBall.run it works. * But If I place the breakpoint in ManyBalls.startApp it doesn't work : java.lang.InternalError: Got event of unknown type at org.eclipse.jdi.internal.request.EventRequestManagerImpl.findRequest(EventRe questManagerImpl.java:498) at org.eclipse.jdi.internal.event.EventImpl.read(EventImpl.java:153) at org.eclipse.jdi.internal.event.EventSetImpl.read(EventSetImpl.java:147) at org.eclipse.jdi.internal.event.EventQueueImpl.remove(EventQueueImpl.java:59) at org.eclipse.jdi.internal.event.EventQueueImpl.remove(EventQueueImpl.java:42) at org.eclipse.jdt.internal.debug.core.EventDispatcher.run(EventDispatcher.java :194) at java.lang.Thread.run(Thread.java:536) This exception is thrown while receiving the class prepare event for the ManyBalls class. Also I have noticed something strange with WTK. When hiting a breakpoint the eclipse debugger use ReferenceTypeImpl.findMethod to check that the method is a "part of a known reference type". But when iterating, the methods are not in the right order (superclass method n, superclass method n-1 ...., class method m, class method m-1 ...) Using j2se they are in the right order. The problem seems to come in ReferenceTypeImpl.allMethods when converting an HashSet into an ArrayList. classId and methodID doesn't have the same form in WTK and j2se. I'm starting to love using eclipse to debug eclipse debugging WTK ;-)
I have replaced the HashSet with a Vector in ReferenceTypeImpl.allMethods and that fixed the last problem. There is the same thing in ReferenceTypeImpl.allInterfaces and ReferenceTypeImpl.allFields but it may cause problem with duplicate entry...
Christophe, can you please open a new bug report for the problems you found? Also, if you're only bringing in a few files from CVS to rebuild, please make sure you're getting all fixes.
Ok, I have open a bug report : Breakpoint hit in parent's class method instead of class method http://dev.eclipse.org/bugs/show_bug.cgi?id=21450
Jared, I observe a behavior similar to what Christophe sees. I also get the following entry in the .log. !ENTRY org.eclipse.jdt.launching 4 4 Jul 11, 2002 07:00:10.483 !MESSAGE Invalid path: java/lang/k:/re/midp/MIDP1/0/3/src/share/classes/java/lang/Class.java. !STACK 1 Java Model Exception: Java Model Status [Invalid path: java/lang/k:/re/midp/MIDP1/0/3/src/share/classes/java/lang/Class.java.] at org.eclipse.core.runtime.CoreException.<init>(CoreException.java:35) at org.eclipse.jdt.core.JavaModelException.<init>(JavaModelException.java:64) at org.eclipse.jdt.internal.core.JavaProject.findElement(JavaProject.java:573) at org.eclipse.jdt.launching.sourcelookup.JavaProjectSourceLocation.findSourceEleme nt(JavaProjectSourceLocation.java:75) at org.eclipse.jdt.launching.sourcelookup.JavaSourceLocator.getSourceElement(JavaSo urceLocator.java:187) at org.eclipse.jdt.debug.ui.JavaUISourceLocator.getSourceElement(JavaUISourceLocato r.java:117) at org.eclipse.debug.internal.ui.views.launch.LaunchView.lookupEditorInput(LaunchVi ew.java:518) at org.eclipse.debug.internal.ui.views.launch.LaunchView.showMarkerForCurrentSelect ion(LaunchView.java:478) I see a fix in org.eclipse.jdt.launching.sourcelookup.JavaSourceLocator for #12966, but it doesn´t seem to fix the problem.
Opened Bug 21483 to address the "event of unknown type" bug Christophe mentions above.
Christian, please open a new bug report for the source lookup problem you're seeing. Be sure to include detailed steps (particularly, how you're setting up your Eclipse project) to reproduce the bug.
created bug #21518 for the source lookup problem
except for #21518: verified
Verified code.
What is the status of the fix for this? Is there a place where I can download the drop where this is fixed? As far as I can tell the latest version of the project on dev.eclipse.org does not contain the fix. We are investigating the same issue when debugging kvms from WSDD.
The fixes from this bug report have been in CVS for a long time. These fixes are definitely in the current integration builds. If you are finding more Eclipse bugs in this area, please open bug reports.
When setting a breakpoint, this error occurs for me with Eclipse M4 and I2003022, JDK 1.4.1_01 and WTK 1.0.4_01 -- see stack trace below. When asked for the method list (in ReferenceType.methods() ), the K Debug Proxy (KDP) returns 0 methods, so MethodImpl.readWithReferenceTypeWithTag cannot find the method, and raises the exception. KDP itself seems to have problems with the type/class file, requests for the type signature of the "offending" type, etc. fail, too. When commenting out the exception raising code in MethodImpl.readWithReferenceTypeWithTag, the debugger "works", i.e. it stops at the break point, the stack trace is shown, etc. However, stepping does not work. java.lang.InternalError: Got MethodID of ReferenceType that is not a member of the ReferenceType at org.eclipse.jdi.internal.MethodImpl.readWithReferenceTypeWithTag(MethodImpl.java:642) at org.eclipse.jdi.internal.LocationImpl.read(LocationImpl.java:152) at org.eclipse.jdi.internal.StackFrameImpl.readWithLocation(StackFrameImpl.java:302) at org.eclipse.jdi.internal.ThreadReferenceImpl.frames(ThreadReferenceImpl.java:196) at org.eclipse.jdi.internal.ThreadReferenceImpl.frames(ThreadReferenceImpl.java:165) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getUnderlyingFrames(JDIThread.java:512) at org.eclipse.jdt.internal.debug.core.model.JDIThread.createAllStackFrames(JDIThread.java:489) at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames(JDIThread.java:365) at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames(JDIThread.java:461) at org.eclipse.jdt.internal.debug.core.model.JDIThread.hasStackFrames(JDIThread.java:2228) at org.eclipse.debug.internal.ui.views.launch.LaunchViewContentProvider.hasChildren(LaunchViewContentProvider.java:88) at org.eclipse.jface.viewers.AbstractTreeViewer.isExpandable(AbstractTreeViewer.java:986) at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:1223) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:897) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:875) at org.eclipse.jface.viewers.StructuredViewer$7.run(StructuredViewer.java:801) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:741) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:799) at org.eclipse.debug.internal.ui.views.launch.LaunchViewer.refresh(LaunchViewer.java:62) at org.eclipse.debug.internal.ui.views.launch.LaunchView.autoExpand(LaunchView.java:836) at org.eclipse.debug.internal.ui.views.launch.LaunchViewEventHandler.doHandleSuspendThreadEvent(LaunchViewEventHandler.java:227) at org.eclipse.debug.internal.ui.views.launch.LaunchViewEventHandler.doHandleSuspendEvent(LaunchViewEventHandler.java:173) at org.eclipse.debug.internal.ui.views.launch.LaunchViewEventHandler.doHandleDebugEvents(LaunchViewEventHandler.java:96) at org.eclipse.debug.internal.ui.views.AbstractDebugEventHandler$1.run(AbstractDebugEventHandler.java:65) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:31) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:94) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:1669) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1414) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1525) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1508) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539)
Opened Bug 30816 for the new bug and added Jochen as CC. As I said in the comment immediately before this bug was reopened, we do not track all bugs in a single bug report. Please open new reports for new bugs.
