Comment 1 Jared Burns 2003-02-21 11:30:23 EST

Note that the above report came from Jochen in Bug 12966.

Jochen, I see that Sun has released a beta of the WTK 2.0. Have you tried it?
Does it solve any of their debug bugs?

Comment 2 Jochen Kuhnle 2003-02-22 04:30:29 EST

Sorry for the posting to the wrong bug, I got confused with my bug bookmarks...
Bug 27826 should have been the target.

We had some configurations tested, none of which worked. The following errors
occured in the various configurations:

1. "MethodID" error: java.lang.InternalError: Got MethodID of ReferenceType that
is not a member of the ReferenceType at
org.eclipse.jdi.internal.MethodImpl.readWithReferenceTypeWithTag(MethodImpl.java:643).
At Breakpoint: Displays correct location, no stack trace, no stepping

2. "Zayit crash" error: Zayit.exe crashes when debugger connects.

3. "Signature" error: Emulator prints „Signature cmd: exception
java.lang.Exception: Couldn't get ClassFile object for signature cmd“

I'll attach a PDF which shows which configuration results in which error. Note
that the J2ME plugin I am writing stopped loading in the PDE between I20030122
and I20030129, so we could not test the latter. I'm investigating that right now
(and will post a seperate error report :).

Comment 3 Jochen Kuhnle 2003-02-22 04:32:11 EST

Created attachment 3647 [details]
Tested configurations

Comment 4 Darin Swanson 2003-03-06 12:16:07 EST

Jochen,  Have you been able to move to a later (latest) build?

Have you tried turning off all exception breakpoints...I have found these cause 
trouble. 
This includes the Java Debug preferences for "Suspend execution on uncaught 
exceptions" and "Suspend execution on compilation errors".

Comment 5 Jochen Kuhnle 2003-04-03 03:48:25 EST

Darin, I have now tested Eclipse 2.1, JDK 1.4.1_02 and WTK 2.0. I also tried
turning off the debug options you mentioned. When attaching to the emulator,
zayit.exe still crashes.
Regards, Jochen

Comment 6 Darin Swanson 2003-04-03 09:27:20 EST

I will do some more investigation on this today.

Comment 7 Craig Setera 2003-08-26 14:39:34 EDT

Darin, 

Has there been any activity on this bug?  I've verified that Netbeans with the
mobile toolkit module is able to correctly handle this debugging.  I'm getting
ready to trace their communications with the emulator to see if I can figure out
what Eclipse is doing differently, but I won't bother if there has been any
significant progress on this bug.

Thanks

Comment 8 Darin Swanson 2003-08-26 14:42:03 EDT

Your help would be appreciated...

Comment 9 Craig Setera 2003-08-26 14:47:52 EDT

I will let you know what, if anything, I'm able to come up with. 

Comment 10 Jochen Kuhnle 2003-08-27 03:46:48 EDT

The easiest way would be to get the WTK sources. I have already tried that, but
you have to be a licensee. Of course I would like to pay loads of money for the
honor to remove their bugs...

But: I am pretty sure that some large company involved in Eclipse development
(like, say, IBM) already has a WTK source license. How about they hand a
subcontract out to us to investigate this bug? I offer to do the work for $0,00.

Comment 11 Craig Setera 2003-08-27 09:58:31 EDT

I'm adding an attachment to the bug containing my initial data capture.  There
is no analysis of this data, but I thought I would get it out to the community
in case others have time to look at this before I do.  I don't really know JDWP
anyway, so my next step is to try to annotate the information that was captured,
but I won't know what is "correct".  Hopefully others that know more can look at
this information and use it to diagnose the problem.

In the zip file, you will find the captured data (*.bin files), the code I used
to capture that data (Proxy subdirectory), a simple merged text output of the
bytes that were captured (proxyout.txt) and the code that was used to create
that file (Proxy subdirectory again).

This was a very simple debug session between Netbeans 3.5.1 with the Mobile
toolkit plugin and Sun's Wireless Toolkit 2.0.

Comment 12 Craig Setera 2003-08-27 09:59:54 EDT

Created attachment 5870 [details]
Data capture  of Netbeans/KVM debug session

Comment 13 Luc Bourlier 2003-08-28 14:40:44 EDT

craig: the jdt.debug plugin contains a tool to trace the communication between a
VM and a debugger. It's a standalone application, the main class is
org.eclipse.jdi.internal.spy.TcpipSpy.

The parameters are:

TcpipSpy <client port> <server host> <server port> [<output file>]
If <output file> is not defined, the trace is print in the standart output.

The spy is working on a debug session where the vm is the server and the
debugger is the client. It should work for the opposite configuration, if you
modify the socket creation code in the main method.

Comment 14 Craig Setera 2003-08-28 15:17:59 EDT

Created attachment 5903 [details]
Data capture of Netbeans and Eclipse debug sessions with KVM

Comment 15 Craig Setera 2003-08-28 15:20:26 EDT

Luc, thanks so much for the tip.  It was looking like a lot of work (that I was
willing to do) to get this much detail.  

I've created a new attachment with the log files for a Netbeans and Eclipse
debug session with the wireless toolkit.  As you can see, the Eclipse session is
very short in comparison.  It crashes very quickly, so that is all that occurred.

I will try to take a look and see if I can understand anything with this
tonight, but those who better know JDI/JDWP will probably have better luck
interpreting this.

Comment 16 Jared Burns 2003-08-28 15:38:49 EDT

<random comment>
Wow... They listen to all class prepare events? With any kind of latency, that 
has to make your application startup brutally slow.
</random comment>

Comment 17 Craig Setera 2003-08-28 15:48:02 EDT

<random comment response>
Yet another reason that so many of us want to use Eclipse and not Netbeans! :-)
Let's get this silly problem fixed so that the world can start using Eclipse to
debug WTK!
</random comment response>

Comment 18 Jared Burns 2003-08-28 16:48:14 EDT

No meaningful differences jump out at me in the logs.

However, I have to ask... Are these logs from a *complete* session? I would 
expect to see some VM_DEATH or VM_DISCONNECTED action at the end.

Comment 19 Craig Setera 2003-08-28 17:10:28 EDT

These logs are from a complete session on the Netbeans side (obviously not for
the Eclipse side).  Here is essentially what I did in Netbeans:

- Created a wireless emulator project.
- Opened WormMain source file in Netbeans.
- Set a breakpoint on the first line of #startApp.
- Started up the WTK emulator by hand.. Here is the command-line
emulator -cp "c:/Documents and Settings/csetera/.netbeans/3.5/examples_me"
-Xdebug
-Xrunjdwp:transport=dt_socket,address=ro-csetera2:22222,server=y,suspend=y
example.wormgame.WormMain
- Started the TcpipSpy listening on port 11111 and connected to 22222.
- Had Netbeans debugger attach to port 11111.
- Resumed the emulator (it is not automatic in Netbeans)
- Single-stepped over a few lines of code after the breakpoint was hit.
- Played around looking at the local variables.
- Resumed execution.
- Chose to Exit on the emulator.

A couple of differences between Netbeans and Eclipse that *might* be coming into
play:
- The fact that Netbeans does not automatically resume execution when it
attaches to the emulator.  Maybe things aren't quite setup in the emulator when
Eclipse attempts to resume the debugged application?  (Timing/concurrency)
- Netbeans does not execute the toString() method for variables in the variables
view, leaving the id's in the viewer.  I think it is ugly given the nice way
that Eclipse works, but maybe that is contributing to the problem?

If there is anything else I can do to help, please let me know.  If you aren't
seeing anything obvious, I doubt I will see anything when looking at the traces.

Comment 20 Luc Bourlier 2003-08-28 19:25:27 EDT

Eclipse has an option to not automatically resume when it attaches to the VM. In
the main tab of the java application launch configuration, check the option
'stop in main'.
And if you hide the detail pane in the variable view ('variable view only' in
the drop-down menu in the toolbar of the variable view), Eclipse should stop to
ask for the toString().

Comment 21 Craig Setera 2003-08-28 20:30:00 EDT

Some interesting ideas, but neither of these helped.

I looked at "stop in main" code and it appears that it essentially sets a
breakpoint in the main method.  The execution of the emulated code still occurs.
 In the case of a midlet there is no main method to set a breakpoint in.  I
don't know if this is how the Netbeans debugger stops before the code is run or
not.  Looking at the JDWP spec, I wonder if they are using VM level
suspend/resume functionality?

In addition, I completely closed the variable view, but that didn't help either.
 Based on a previous comment for this bug, I've also got caught and uncaught
exceptions deselected as well which didn't help either.

I will keep trying any ideas that people have.

Comment 22 Jared Burns 2003-08-28 20:41:45 EDT

SocketAttachConnector#connect calls the version of 
JDIDebugModel#newDebugTarget() which *doesn't* take the "resume" argument. This 
method then calls the method that takes resume as a parameter, passing in true. 
If you hack SocketAttackConnector#connect (currently line 133) to call the other 
method and pass in false, the debugger will connect and the VM will stay 
suspended.

When I tested this quickly, the VM crashed when I resumed it. :)

Comment 23 Craig Setera 2003-08-28 21:32:08 EDT

I see the exact same results.  What is Eclipse doing differently on resume than
Netbeans?  Seems like a pretty normal thing to do! :-)

Comment 24 Craig Setera 2003-09-04 15:11:10 EDT

I was thinking some more about this.  Is there a chance that those CLASS PREPARE
events are important to the KVM?  Is there a change that the fact that Eclipse
doesn't request them somehow keeps the VM from being correctly initialized
during debugging?  I attempted to hack up my JDI plugin to request all class
prepare events, but I obviously didn't do it correctly and debugging just
completely hung.

Are there any other thoughts or approaches that can be taken?

Comment 25 Jared Burns 2003-09-17 13:00:24 EDT

Sorry for not replying to this sooner. It seems unlikely that the KVM is 
dependant on these class prepare requests. If it's the problem, it would be 
useful to know, but we (I) wouldn't change our debugger to request that many 
unneccessary notifications.

Comment 26 Jared Burns 2003-09-17 13:05:20 EDT

Our experience has always been that the KVM's debugger is flaky at best. We've 
already made a couple allowances in our JDI client that make us work a little 
better with the KVM's spec violations, but finessing the debugger to suit the 
KVM isn't a priority for us.

If anyone has insights (or patches), I'll be happy to explore them, but I'm not 
actively looking at this problem otherwise. Adding "helpwanted" keyword as a 
hint. :)

Comment 27 Craig Setera 2003-09-17 17:43:36 EDT

What is the next step for this?  I'm getting ready to release a new version of
EclipseME (this weekend?) in which I will have the debug support enabled in the
plugin, knowing full well that it won't work.  My current plan is to point
people to this bug report and tell them that when this bug is fixed debugging
midlets should just magically work.  I'd really like to help get this fixed, but
I'm unclear what more I can do to help you out.

Does IBM have access to the source for the wireless toolkit or have they stayed
away from that to avoid contamination with the J9 based wireless stuff? 
Obviously the easiest way to figure this out would be to have the source for the
wireless toolkit and debug the emulator.

Comment 28 Jared Burns 2003-09-17 18:06:07 EDT

The next step is for someone (you? :-)   ) to decide that this problem is important enough to them to 
work on it. If you find specific bugs in Eclipse that are causing these failures, I'll be happy to fix 
them.

We implement the JDI interface and communicate with the VM using the JDWP protocol, both 
specified here:
http://java.sun.com/j2se/1.3/docs/guide/jpda/index.html

Comment 29 Craig Setera 2003-09-18 08:21:40 EDT

I'm not going to argue that the emulator is probably at fault.  Please
understand that I was in no way trying to push this problem off to you or any of
the other folks working on Eclipse debugging.  With that said, I've looked at
the JDI/JDWP spec and I'm willing to look some more, but I'm definitely not well
versed in the whole thing.  It has always been my hope that I could work *with*
the Eclipse team and together we would find a solution.

On a related note, I sent a note to Sun last night in hopes of getting some help
from the direction.  I don't hold out much hope on that front, but felt it was
necessary.

Comment 30 Kerry McNeil 2003-10-02 17:01:07 EDT

We are having a similar problem trying to run debug in eclipse for the Nokia 
emulator. It connects, then disconnects from KVM immediatley. I can set and 
step through a breakpoint using the WTK, so maybe that problem is now fixed.  
Is this an eclipse or an emulator problem?
We call:
JDIDebugModel.newDebugTarget(launch, vm, vmLabel, null, allowTerminate, 
true);     for Nokia and WTK, but only WTK works.

Comment 31 Darin Wright 2003-10-02 17:07:38 EDT

As far as we know, this is a WTK problem.

Comment 32 Kerry McNeil 2003-10-03 11:42:37 EDT

Tried to debug on the Sun Wireless Toolkit v2.0 (as that is what nokia is 
based on) and it works as long as I uncheck the following options 

Window > Preferences > Java > Debug 
     Suspend execution on uncaught exceptions
     Suspend execution on compilation errors

I can stop in the debugger, step through MIDlet code etc...

Comment 33 Craig Setera 2003-10-03 20:23:16 EDT

Kerry,

I'm unable to get even as far as you mention.  I've got the preferences set as
you mention.  What versions of things are you using?  For instance:
- Operating System
- Wireless Toolkit
- Anything else.

Also, what are the command line parameters you are using for the toolkit emulator?

Comment 34 Kerry McNeil 2003-10-06 10:24:18 EDT

Windows 2000
Eclipse 2.1.1
latest WTK downloaded from Sun
Window > Preferences > Java > Debug 
     Suspend execution on uncaught exceptions
     Suspend execution on compilation errors
Click on Devices,  new UEI, then pick the WTK install directory for the 
emulator.exe.  Use all defaults.

Comment 35 yinglcs 2003-10-17 23:58:52 EDT

Kerry, 

Could you please tell me how you get that to work?

Specifically, what you mean by "Click on Devices,  new UEI, then pick the WTK
install directory for the emulator.exe.  Use all defaults."

I try both Eclipse 3.0 M4 and 2.1.1 on Window xp with WTK 2.0, but I can't get
that to work.

here is the step I do:
1. create an eclipse project which use the photoalbum example as its source.
2. open the ktoolbar in the WTK, open the photoalbum project.
3. in the ktoolbar, select Debug and enter port 5002.
4. in eclipse, add new Remote Application Debug and enter port 5002.
5. un-check the following in eclipse preference:
 Suspend execution on uncaught exceptions
     Suspend execution on compilation errors
6. click the debug. 

I did see the conneciton established, but it crashes afterward. 
I appreciate if you can tell me how you get that to work. Thanks.

Comment 36 Kerry McNeil 2003-11-18 08:46:50 EST

Sounds like you are doing it right, problem is I'm working on the unreleased 
code for WSDD and the newest unreleased emulators.  We are releasing in January 
I believe.

Comment 37 Craig Setera 2003-11-19 16:02:59 EST

Does anyone have an idea when these new emulator versions will become publically
available?  Does anyone have an idea if it would be possible for me to get an
early release somehow?

Comment 38 Craig Setera 2003-11-20 21:26:17 EST

There is a new beta version of the Wireless Toolkit available at
http://wireless.java.sun.com.  There have been a number of changes that have
broken EclipseME, but I was able to do some hacking and test out this beta.  It
doesn't appear to work any better than 2.0.  

Can anyone else give this a shot and see if they have any better luck?  It
should be possible to launch a midlet from KToolbar with debugging enabled and
then do a remote debug from Eclipse, but doesn't seem to be working for me.

Everyone should also send a note to wtk-comments@sun.com and let Sun know that
you want WTK to be debuggable by Eclipse.  I don't know if it will help, but it
seems more possible to get changes during a beta period.

Comment 39 Luc Bourlier 2003-11-21 11:38:47 EST

The problem is more with KVM than with WTK. The differente versions of WTK and
the Nokia emulator I saw are all using the same version of KVM, 1.0.3.
This version of KVM doesn't behave well when the Eclipse java debugger is
attached to it. It crashes for an unknown reason. Even if the Eclipse java
debugger was sending bad requests, the VM shouldn't crash but send an error back.

Comment 40 Craig Setera 2003-12-29 17:42:53 EST

I've spent the day looking at this and have some more information, although I
still don't know how to "fix" this problem.

I was able to debug through a Midlet using Eclipse, but only if I set a
breakpoint in the resume method of the
org.eclipse.jdi.internal.VirtualMachineImpl class in the workbench that was
debugging the runtime workbench.  The breakpoint would be hit twice during the
time that the runtime workbench debugger was connecting to the KVM.  After
resuming the debugging of the debugger for each breakpoint, I was able to single
step through breakpoints I had set in the Midlet in the runtime workbench.

I can't say that I know exactly what this means, as I still don't have a good
feel for how the JDI code fits together.  For instance, I did notice that the
two resume method calls originated from different threads in the debugging
support.  It does, however, appear to be somehow concurrency related as opposed
to the actual ordering of the event requests from Eclipse to the KVM.

In terms of the class prepare events, it does appear that those events are
necessary in order for the line number lookups to work while debugging.  I was
able to break in the Midlet without them enabled, but was debugging "blind" in
that case.  I was able to enable the class preparation events only for the KVM
by adding the following to the getVersionInfo method of the VirtualMachineImpl
class.

			fVMName = readString("name", replyData); //$NON-NLS-1$
			
			if ((fVMName != null) && fVMName.equals("KVM")) {
				// KVM requires class preparation events in order
				// to resolve things correctly
				eventRequestManagerImpl().enableInternalClassPrepareEvent();
			}

I'm not sure that this is the appropriate place to handle this, but I know there
is concern about having all of these events flowing.  It does seem reasonable to
do it for KVM only.

So, can anyone offer any insights into the correct solution to handle the
trouble with the resume function?

Comment 41 Darin Wright 2004-01-07 17:07:57 EST

I am able to reproduce the problem as stated. I can get the emulator to start 
if I put a breakpoint in the code that resumes the VM. The first request to 
resume is performed when we receive a VMStart event, and the second request to 
resume is in response to a class load event for java.lang.Throwable.

Comment 42 Craig Setera 2004-01-18 19:09:45 EST

I've made some progress on getting things to work, although things are a bit of
a hack right now.  I'm definitely looking for input from those who know the best
direction.  In essence, it appears that the KVM is just plain slow.  Other than
the necessity to request class prepare events to get line number information
correct, it seems that if I slow things down on the Eclipse side it is possible
to debug (albeit with a few odditities).  Here is what I've done to get this
working so far.

As previously discussed, class prepare events are necessary for any of this to
work.  I added 
			if ((fVMName != null) && fVMName.equals("KVM")) {
				// KVM requires class preparation events in order
				// to resolve things correctly
				eventRequestManagerImpl().enableInternalClassPrepareEvent();
			}

to VirtualMachineImpl#getVersionInfo to request class prepare events. I added 

	public void enableInternalClassPrepareEvent() {
		// Note that these requests are not stored in the set of outstanding requests
because
		// they must be invisible from outside.
		ClassPrepareRequestImpl requestPrepare =
			new ClassPrepareRequestImpl(virtualMachineImpl());
		requestPrepare.setGeneratedInside();
		requestPrepare.setSuspendPolicy(ClassPrepareRequest.SUSPEND_NONE);

		requestPrepare.enable();
	}

to EventRequestManagerImpl to make this work.

I noticed a lot of JDI Timeout exceptions in the log file.  By increasing the
JDI timeout value in the preferences to 15000 millis those exceptions went away
and things started to stabilize.  I'm not sure what the ideal timeout value
would be.

The emulator was still crashing or hanging during startup.  I added the
following to the start of VirtualMachineImpl#resume to get things started up.

	public void resume() {
		if ((fVMName != null) && fVMName.equals("KVM")) {
			// KVM is **SLOW**... Give it a chance to catch up.
			try { Thread.sleep(1000); } catch (InterruptedException e) {}
		}

		initJdwpRequest();

So, it appears with some minor changes, Eclipse can debug the J2ME KVM. 
Admittedly, I'm not sure that the changes I made are the "correct" or "clean"
changes.  They do seem to work though.  I'm hoping that someone with a better
understanding of all of the debugging code might be able to suggest a better
solution and that we can look at getting something that the general public can
use.  For instance, is it possible to provide a KVM-specific extension to the
JDI support that could be wrap these differences separately?

Thanks.

Comment 43 Darin Wright 2004-01-19 09:04:39 EST

Thanks for your input.

I found that by doing the following, I was able to debug the KVM:

* disable (in code) "suspend on uncaught exceptions" & "suspend on compilation 
error" options
* change the handling of the VMStart event slightly - we usually ask the VM 
for its existing threads (to initialize state) before we receive the VMStart 
event. If I wait until after the VMStart event, things seem to work better.

I would rather not code special case handling for KVM - it should work like 
any VM (that is the whole premise of JDI). More investigation is still 
required.

Comment 44 Craig Setera 2004-01-19 09:14:50 EST

Darin,

Thanks much for the update.  Are your changes in addition to those I mentioned
or do they somehow make my changes unnecessary?

I appreciate your work on this.  I know there are a lot of other people who are
similarly interested in being to using their favorite IDE to develop for the
KVM.  As usual, anything I can do to help the cause, just let me know.  

I agree it would be nice to have one implementation that works for all VM's, but
I'm also interested in seeing this work for people as soon as possible.  It was
very nice to step through KVM code yesterday to solve a problem rather than
guess and println's.  Is there any chance we could get a non-supported patch
version of the plugin for people until you figure out the best way to handle? 
I've been considering switching to requiring 3.0 as of the M7 milestone for
EclipseME.  If people could get a "hacked" JDI plugin for M7, I'm sure there
would be a lot of happy people.

Thanks.

Comment 45 Darin Wright 2004-01-19 09:21:10 EST

The changes I made are mutually exclusive to the changes you made - i.e. the 
only changes I made are the ones I mentioned. I can't promise a fix for M7 at 
the moment - but we are getting closer.

Comment 46 Darin Wright 2004-01-21 23:25:17 EST

I also found that the KVM is returning an invalid thread status code, 
according to the JDWP spec. Valid return codes for thread status are: 0, 1, 2, 
3, 4. However, the KVM is returning -1.

Comment 47 Craig Setera 2004-01-22 08:52:38 EST

Does this mean that there is no way you can make it work without Sun's help?  My
requests for help from them have gone into a black hole and never returned.  I
know you aren't thrilled with making KVM-specific workarounds, but I'm not
convinced I will ever make any progress with Sun.

I really appreciate your time in looking at this.

Comment 48 Darin Wright 2004-01-22 12:55:35 EST

I have released what I found to be a minimal fix, to the 3.0 HEAD stream, 
which has little/no impact on other VMs.

Findings:
* The KVM reports an undocumented thread status of "-1", with an associated 
suspend status of "1" when we attach to the KVM. Our debugger interpretted 
this as "thread suspended", when in actual fact, it appears the thread is 
actually running. I modified the debugger's thread initialization code to 
check for a status of "-1" (which I assume is THREAD_STATUS_UNKNOWN), and 
treat the thread as "running".
* The KVM dies when exception breakpoints are set for 
both "java.lang.Throwable" and "java.lang.Error" in a disabled state, or when 
both breakpoints are set for "uncaught" locations only (which is what our 
suspend on uncaught exceptions/compilataion errors code does). I altered our 
client to add/remove the breakpoints rather than register the breakpoint 
requests in a disabled state. This avoids adding the breakpoints to target VMs 
when the options are off. It appears you can use either option by itself, but 
you can not use both options at once.

With these fixes, the user notes are:
* Increase the "Debugger Timeout" to some value (I used 15,000). It's not 
clear that this is required, but it appears happy.
* Turn off the "Suspend on uncaught exceptions" & "Suspend on compilation 
errors" preferences (or only leave one of them on)

Comment 49 Darin Wright 2004-01-22 13:11:18 EST

Note: in 3.0, you need to turn the "system thread" filter off to see the KVM 
threads (which all appear as system threads). The filter toggle is available 
in the debug view drop-down menu.

Will attach patches for debug plug-ins to be applied to 3.0 I20040121 build, 
for testing.

Comment 50 Darin Wright 2004-01-22 13:15:52 EST

Created attachment 7527 [details]
replacement plug-in for org.eclipse.jdt.debug

Comment 51 Darin Wright 2004-01-22 13:16:32 EST

Created attachment 7528 [details]
replacement plug-in for org.eclipse.jdt.debug.ui

Comment 52 Craig Setera 2004-01-22 15:01:21 EST

Darin,

Thanks for all of your work on this.  I will try out the patches you attached
tonight.

A question about the preferences that need to be specified to do KVM debugging.
 Any chance we can see those preferences attached to a project in the future?  I
can see cases where I would want those settings set one way for J2ME debugging
and another for J2SE... Especially the uncaught exceptions.  It would be awesome
if those could be set like the compiler options.  Defaults in the preferences
and overrides on a project level.

Comment 53 Darin Wright 2004-01-22 15:12:01 EST

Thanks, I would appreciate feedback on the fix. My KVM/WTK experience is 
limited, so I have done minimal testing.

As for your "preference request", I suggest entering it as a new feature 
request.

Comment 54 Craig Setera 2004-01-22 19:36:29 EST

I tried to overlay the latest Integration build with the patched version and
lost all JDT functionality (views,etc).  I deleted the directories and tried
again with the same results.  Is there some trick I'm missing?

Comment 55 Darin Wright 2004-01-22 21:22:20 EST

Delete the ".registry" file in the ".config" folder of your Eclipse 
installation directory. For some reason this needs to be re-built.

Comment 56 Craig Setera 2004-01-23 18:22:03 EST

Darin,

With this new code, things look much, much better.  A couple of minor things I
noticed:

1) The variables detail view doesn't seem to work.  Something about an
UnsupportedOperationException.  It looks like the KVM doesn't support executing
a method to retrieve that information?  Closing that view doesn't cause any real
trouble, although I've always liked that view.

2) When I expand the "this" variable, I see the following errors on every step.
 If the tree isn't expanded, I don't see the errors.  Don't know if there is
anything that can be done or not.

Signature cmd: exception java.lang.Exception: Couldn't get ClassFile object for
signature cmd
Interfaces cmd: exception java.lang.Exception: Couldn't get ClassFile object for
Interfaces cmd
Signature cmd: exception java.lang.Exception: Couldn't get ClassFile object for
signature cmd
Interfaces cmd: exception java.lang.Exception: Couldn't get ClassFile object for
Interfaces cmd
Signature cmd: exception java.lang.Exception: Couldn't get ClassFile object for
signature cmd
Interfaces cmd: exception java.lang.Exception: Couldn't get ClassFile object for
Interfaces cmd
Signature cmd: exception java.lang.Exception: Couldn't get ClassFile object for
signature cmd
Signature cmd: exception java.lang.Exception: Couldn't get ClassFile object for
signature cmd
Signature cmd: exception java.lang.Exception: Couldn't get ClassFile object for
signature cmd
Signature cmd: exception java.lang.Exception: Couldn't get ClassFile object for
signature cmd
Signature cmd: exception java.lang.Exception: Couldn't get ClassFile object for
signature cmd
Signature cmd: exception java.lang.Exception: Couldn't get ClassFile object for
signature cmd

Comment 57 Darin Wright 2004-01-23 21:55:45 EST

Thanks. I going to mark this bug as verified, and then I will open new bugs 
for the newly reported problems (this one has been open too long). It could be 
that the KVM does not support method invocation that we use for 'toString()'.

Filed bug 50530 and bug 50531.

Comment 58 Silvano Maffeis 2004-04-05 03:01:44 EDT

I was now able to debug a MIDlet using the Nokia Series 60 MIDP
emulator and Eclipse 3.0 M8. Darin's recommendadtions have to be
followed:

* Increase the "Debugger Timeout" to some value (I used 15,000). It's not 
clear that this is required, but it appears happy.
* Turn off the "Suspend on uncaught exceptions" & "Suspend on compilation 
errors" preferences (or only leave one of them on)

Comment 59 Darin Wright 2004-07-29 16:06:24 EDT

*** Bug 28037 has been marked as a duplicate of this bug. ***