Community
Participate
Working Groups
I have been trying to attach the eclipse debugger to the Emulator for the J2me Wireless toolkit to debug J2Me MIDlets. I've played around with it alot and have hooked up the jdb command line debugger to it without any hassles though I am still stumped about getting eclipse to connect properly. The midlet has been build with debugging information on and running the bat supplied allows the jdb to connect. When I try and connect with eclipse it connects and finds the KVM thread but doesn't run the MIDlet and when I suspend the thread and inspect it there are parts that it can't determine. On the emulator side (in the cmd window) it does complain that it can find no line number table for java.lang.Object but this is only after suspending the thread, and also it asks for the path to the source code and though I give it the path it still asks every time I select a part of the suspended thread stack. I downloaded the 2.0.2 build and ran it and as before I'm only seeing one thread the System Thread [KVM_Thread..]. It failed differently though (even different failures are encouraging) when looking for the line table in java.lang.Object and the error was !MESSAGE com.sun.jdi.InternalException: Got error code in reply: 41 occurred retrieving source name debug attribute. !STACK 0 com.sun.jdi.InternalException: Got error code in reply: 41 at org.eclipse.jdi.internal.MirrorImpl.defaultReplyErrorHandler (MirrorImpl.java:255) at org.eclipse.jdi.internal.MethodImpl.getLineTable(MethodImpl.java:142) at org.eclipse.jdi.internal.MethodImpl.location(MethodImpl.java:513) at org.eclipse.jdt.internal.debug.core.model.JDIStackFrame.getSourceName (JDIStackFrame.java:798) at org.eclipse.jdt.internal.debug.ui.JavaDebugOptionsManager.getProblem (JavaDebugOptionsManager.java:627) at org.eclipse.jdt.internal.debug.ui.JavaDebugOptionsManager.breakpointHit (JavaDebugOptionsManager.java:596) at org.eclipse.jdt.internal.debug.core.JDIDebugPlugin.fireBreakpointHit (JDIDebugPlugin.java:309) at org.eclipse.jdt.internal.debug.core.model.JDIThread.handleSuspendForBreakpoint (JDIThread.java:877) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.suspend (JavaBreakpoint.java:280) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.handleBreakpointE vent(JavaBreakpoint.java:268) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.handleEvent (JavaBreakpoint.java:235) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaExceptionBreakpoint.handleEv ent(JavaExceptionBreakpoint.java:307) at org.eclipse.jdt.internal.debug.core.EventDispatcher.dispatch (EventDispatcher.java:129) at org.eclipse.jdt.internal.debug.core.EventDispatcher.run (EventDispatcher.java:202) at java.lang.Thread.run(Unknown Source) Any ideas as to why it fails? TIA Stephen Gargan
Created attachment 2744 [details] Files needed to run the test MIDlet in the emulator with the debugging information Don't compile the classes as they need to be modified with a preverification tool that tests them for J2ME compatability (adds a stack map attribute to each function) and the emulator will reject them if they haven't been preverified. Run the bat to fire up the emulator in debug mode with the test MIDlet and then try and connect to the debug port 5000.
I have been working with Stephen on this one offline. On the latest build 20021204 I see different behavior than on the 2.0.2 build but currently it seems breakpoints do not work. The breakpoint shows as installed and execution is suspended but not where the breakpoint is set. The thread claims to be suspended at the correct location but we show a stack track and top stack frame that does not match.
This sounds suspiciously like bug 12740 (which was fixed - could we have re- introduced a similar bug?)
Using the WTK2.0 beta, breakpoints appear to be functioning...at least with Stephen's test case. Still some problems: does not work when have the preferences set to suspend on compilation errors or on uncaught exceptions. I turned these off to have success. some of the threads show up as suspended when they should not be. Stephen is it possible for you to try with WTK2.0beta?
I've downloaded the new WTK beta and the latest milestone of eclipse to test with mixed results. While it says that it is hitting the breakpoint and allegedly stopping (it says that the brkpt was hit and the thread suspended in the debug window) but the emulator never stops at the line and prints out the 'Hello World' in the console when it should really wait to be told to execute this by the debugger. Is the emulator actually pausing & stepping properly for you?
On 20030107 eclipse build If I turn off the Window->Preferences->Java->Debug->Suspend * preferences, I pause at the breakpoint (with no HelloWorld to the console). Step over produces the HelloWorld.
Stephen, what is your status on this problem?
Resolving to investigate more after 2.1 and with the latest WTK.
Marking as later
This has been addressed in 3.0
*** This bug has been marked as a duplicate of 30816 ***
