After years of using it, I've become dependent on the debugger feature, Drop To Frame (described here, here, and here). Briefly, it allows you to select any level (frame) in the call stack during debugging and force the JVM to rollback to that point. It's a little difficult to explain briefly, but trust me when I say that once you've used it you quickly learn to depend on it.
So you can imagine my dismay when I recently started doing all of my Eclipse work on Mac OS X and discovered that Drop To Frame is disabled. It is a feature that not all JVMs support (specifically, those prior to Java 1.4), but I just can't believe that the modern Mac JVMs don't (I've tried running my apps in both Java 5 and Java 6 JVMs).
I asked about this on the Eclipse newsgroups/forums and on IRC, but no response so far. I'm hoping that the blogosphere might have some more insight...
Update: it seems that Drop to Frame is enabled sometimes, but only part-way down the stack, and sometimes not at all. The app I'm debugging has no native code in it, so that's not the culprit in this case. So I'm still looking for some insight into what enables/disables the feature.
Subscribe to:
Post Comments (Atom)
7 comments:
Interestingly, this seems to work fine if you are in a breakpoint of a method, change the code of that method and save. The code gets hot-replaced, and it jumps back to the initial state of the current frame. Or is that something completely different?
@Kristian: Yes, I'm pretty sure the code hot-swap feature is related. That just makes this all the more confusing. :-(
Weird. I use it all the time (i.e. I know for sure I used it today a couple times). I'm using Java 5.0 with Eclipse 3.5-based Carbon app debugged by Eclipse 3.5/Cocoa32 IDE.
I never noticed any probs with it.
Hot swap also works as expected...
Hi Eric, I can corroborate what zzhou said - it works here in Eclipse 3.5 on Cocoa 32 under Java 5. I just checked. I'll also check in Eclipse Cocoa 64 if you want.
Well, I am using the 64-bit version (Cocoa), so perhaps that is the difference? Although I would think that the availability of this feature is driven by the JVM running my application, not the JVM that Eclipse is running in.
To me Cocoa64/Java6 didn't look really stable (Cocoa64/Java5 looked much better, I'm using Cocoa32/Java5 as dev. IDE). So our product stays Carbon/Java5. It could be that Eclipse has problems with Apple Java6 in other departments, not only SWT.
I just tested it in Cocoa/64 under Java 6, and it worked as well. I was debugging an Eclipse Cocoa 64 runtime, so the Java 6 VM does support the feature. It looks like there's something wrong with your configuration?
Post a Comment