Community
Participate
Working Groups
I was working in the Java EE perspective when suddenly the Debug perspective took over and this error popped up What steps will reproduce the problem? 1. No idea 2. 3. -- Error Details -- Date: Fri Jul 26 15:13:54 PDT 2013 Message: java.lang.InternalError: Got MethodID of ReferenceType that is not a member of the ReferenceType occurred retrieving stack frames. Severity: Error Product: Eclipse 2.0.0.20130613-0530 (org.eclipse.epp.package.standard.product) Plugin: org.eclipse.jdt.debug.ui Session Data: eclipse.buildId=4.3.0.I20130605-2000 java.version=1.7.0_25 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_CA Framework arguments: -product org.eclipse.epp.package.standard.product Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.standard.product This is a continuation of log file W:\workspace\.metadata\.bak_0.log Created Time: 2013-07-25 10:17:21.415 Exception Stack Trace: java.lang.InternalError: Got MethodID of ReferenceType that is not a member of the ReferenceType at org.eclipse.jdi.internal.MethodImpl.readWithReferenceTypeWithTag(MethodImpl.java:697) at org.eclipse.jdi.internal.LocationImpl.read(LocationImpl.java:169) at org.eclipse.jdi.internal.StackFrameImpl.readWithLocation(StackFrameImpl.java:354) at org.eclipse.jdi.internal.ThreadReferenceImpl.frames(ThreadReferenceImpl.java:275) at org.eclipse.jdi.internal.ThreadReferenceImpl.frames(ThreadReferenceImpl.java:240) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getUnderlyingFrames(JDIThread.java:664) at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames(JDIThread.java:563) at org.eclipse.jdt.internal.debug.core.model.JDIThread.computeStackFrames(JDIThread.java:635) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getTopStackFrame(JDIThread.java:1212) at org.eclipse.jdt.internal.debug.ui.breakpoints.SuspendOnCompilationErrorListener.breakpointHit(SuspendOnCompilationErrorListener.java:65) at org.eclipse.jdt.internal.debug.core.breakpoints.BreakpointListenerManager$JavaBreakpointListenerProxy.breakpointHit(BreakpointListenerManager.java:160) at org.eclipse.jdt.internal.debug.core.JDIDebugPlugin$HitNotifier.run(JDIDebugPlugin.java:736) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.jdt.internal.debug.core.JDIDebugPlugin$AbstractNotifier.notifyListeners(JDIDebugPlugin.java:541) at org.eclipse.jdt.internal.debug.core.JDIDebugPlugin$HitNotifier.notifyHit(JDIDebugPlugin.java:752) at org.eclipse.jdt.internal.debug.core.JDIDebugPlugin.fireBreakpointHit(JDIDebugPlugin.java:493) at org.eclipse.jdt.internal.debug.core.model.JDIThread.handleSuspendForBreakpoint(JDIThread.java:1298) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.suspend(JavaBreakpoint.java:401) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaExceptionBreakpoint.handleBreakpointEvent(JavaExceptionBreakpoint.java:387) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.handleEvent(JavaBreakpoint.java:308) at org.eclipse.jdt.internal.debug.core.EventDispatcher.dispatch(EventDispatcher.java:152) at org.eclipse.jdt.internal.debug.core.EventDispatcher.access$0(EventDispatcher.java:100) at org.eclipse.jdt.internal.debug.core.EventDispatcher$1.run(EventDispatcher.java:249) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Got the same warning pop-up while creating conditional breakpoint with the condition for one of the parameters to be null. Does not bother me if putting the breakpoint one step upper in stack in the function call instead of inside the function itself. JDK - 1.7040, Eclipse - STS 2.8.1.RELEASE, Windows 7 sp1
It would be good if I had a test case and steps to reproduce since I have not been unable to reproduce smoke testing / using the test suites.
Thanks for your response. Actually I found out that STS 2.8.1.RELEASE (our recommended corporate environment) is based on Eclipse 3.7.2 Indigo SR2. So It may be to old and this problem is probably fixed already.
I am experiencing this bug with: Eclipse Java EE IDE for Web Developers. Version: Kepler Service Release 1 Build id: 20130919-0819 I see this bug reported from conditional breakpoints that are checking nullness. These conditions can be as simple as "cal == null" where cal is a local Calendar variable.
I am experiencing this bug as well on Maverick OSX Eclipse Standard/SDK Version: Kepler Service Release 1 Build id: 20130919-0819
By chance do any of you use the "Java Decompiler" Eclipse plugin or DCEVM?
It's hard to say for sure. But after switching to the old debugger in the JRebel plugin, hot reloading and debugging seem to work for me again.
(In reply to Erki from comment #6) > By chance do any of you use the "Java Decompiler" Eclipse plugin or DCEVM? I have the decompiler plugin installed
(In reply to George Lindholm from comment #8) > (In reply to Erki from comment #6) > > By chance do any of you use the "Java Decompiler" Eclipse plugin or DCEVM? > > I have the decompiler plugin installed Can anyone reproduce this using a vanilla version of Eclipse (with nothing else installed) from : http://download.eclipse.org/eclipse/downloads/ I am still not able to reproduce. The error is indicating that a method ID was returned from the VM that is not a member of the type in the VM, so this is either a VM problem or there are other tools modifying the classfiles (incorrectly).
(In reply to Erki from comment #6) > By chance do any of you use the "Java Decompiler" Eclipse plugin or DCEVM? I have only added the Subclipse related plugins from tigris.org. Everything else is what came standard with the Java EE flavor of Eclipse.
I'm occasionally seeing the same error message (though with a slightly different stacktrace) on 64-bit Linux, Eclipse ; unfortunately I have quite a few plugins installed so it might as well be a plugin issue :( Eclipse Kepler SR1 , 20130919-0819 JDK 1.7.0_51
Created attachment 240315 [details] Eclipse configuration
Created attachment 240316 [details] Installed plugins window screenshot
Sorry, forgot to mention that I'm on a 64-bit system. I attached my Eclipse config along with a screenshot of the "installed plugins" window to this ticket. The stacktrace I'm getting is: !ENTRY org.eclipse.core.jobs 4 2 2014-02-26 08:15:18.465 !MESSAGE An internal error occurred during: "child count update". !STACK 0 java.lang.InternalError: Got MethodID of ReferenceType that is not a member of the ReferenceType at org.eclipse.jdi.internal.MethodImpl.readWithReferenceTypeWithTag(MethodImpl.java:697) at org.eclipse.jdi.internal.LocationImpl.read(LocationImpl.java:169) at org.eclipse.jdi.internal.StackFrameImpl.readWithLocation(StackFrameImpl.java:354) at org.eclipse.jdi.internal.ThreadReferenceImpl.frames(ThreadReferenceImpl.java:275) at org.eclipse.jdi.internal.ThreadReferenceImpl.frames(ThreadReferenceImpl.java:240) at com.zeroturnaround.jdi.JRThreadReference.frames(JRThreadReference.java:57) at com.zeroturnaround.jdi.JRThreadReference.frameCount(JRThreadReference.java:50) at org.eclipse.jdi.internal.ThreadReferenceImpl$$$jr.frameCount(<generated>:60000) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getUnderlyingFrameCount(JDIThread.java:700) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getFrameCount(JDIThread.java:3227) at org.eclipse.jdt.internal.debug.ui.monitors.JavaThreadContentProvider.getChildCount(JavaThreadContentProvider.java:44) at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider.retrieveChildCount(ElementContentProvider.java:114) at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider$2.run(ElementContentProvider.java:63) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
btw, I also have decompiler plugins + JRebel installed (should've read the previous comments more thoroughly, sorry)
(In reply to Tobias Gierke from comment #15) > btw, I also have decompiler plugins + JRebel installed (should've read the > previous comments more thoroughly, sorry) Are there any entries in the console? I finally saw this exception today (on Mac OSX, 1.7.50) which was caused by an OutOfMemoryException. If the VM is in a bad state, that would definitely cause weird errors like this (where the owning class of a method handle has gone missing).
(In reply to Michael Rennie from comment #16) > (In reply to Tobias Gierke from comment #15) > > btw, I also have decompiler plugins + JRebel installed (should've read the > > previous comments more thoroughly, sorry) > > Are there any entries in the console? I finally saw this exception today (on > Mac OSX, 1.7.50) which was caused by an OutOfMemoryException. If the VM is > in a bad state, that would definitely cause weird errors like this (where > the owning class of a method handle has gone missing). I have not seen any entries in the console. I've also continued to work long after experiencing this error and have not seen any indication that the VM was in a bad state.
I'm seeing this quite often with Eclipse Luna SR1 (M20140925-0400) when debugging. I never saw this before, but recently it happens quite frequently. It seems like it happens when a breakpoint is hit quickly after I resume the execution after a previous breakpoint hit, so I suspect it might be a concurrency problem. I don't have any OutOfMemory error and no previous error that might be related to this. The stack trace is the same as the above for the top lines, but then it is different from JRThreadReference.java:57 on. eclipse.buildId=4.4.1.M20140925-0400 java.version=1.8.0_25 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=it_IT Command-line arguments: -os win32 -ws win32 -arch x86_64 org.eclipse.core.jobs Error Mon Dec 15 14:28:16 CET 2014 An internal error occurred during: "child count update". java.lang.InternalError: Got MethodID of ReferenceType that is not a member of the ReferenceType at org.eclipse.jdi.internal.MethodImpl.readWithReferenceTypeWithTag(MethodImpl.java:697) at org.eclipse.jdi.internal.LocationImpl.read(LocationImpl.java:169) at org.eclipse.jdi.internal.StackFrameImpl.readWithLocation(StackFrameImpl.java:354) at org.eclipse.jdi.internal.ThreadReferenceImpl.frames(ThreadReferenceImpl.java:275) at org.eclipse.jdi.internal.ThreadReferenceImpl.frames(ThreadReferenceImpl.java:240) at com.zeroturnaround.jdi.JRThreadReference.frames(JRThreadReference.java:57) at com.zeroturnaround.jdi.JRThreadReference.frameCount(JRThreadReference.java:50) at org.eclipse.jdi.internal.ThreadReferenceImpl$$$jr.frameCount(<generated>:60000) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getUnderlyingFrameCount(JDIThread.java:700) at org.eclipse.jdt.internal.debug.core.model.JDIThread.getFrameCount(JDIThread.java:3227) at org.eclipse.jdt.internal.debug.ui.monitors.JavaThreadContentProvider.getChildCount(JavaThreadContentProvider.java:44) at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider.retrieveChildCount(ElementContentProvider.java:118) at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider$2.run(ElementContentProvider.java:67) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
I get this error frequently. My stack trace looks similar to Maurio's and Tobias'. I'm using a 64-bit installation on Win7. One thing that the three of us have in common is stack frames from JRebel (com.zeroturnaround). Perhaps I will see if zeroturnaround has any insight into what causes it.
It appears that there are multiple vectors for raising this error. I apologize to the OP with what follows, because this information is probably not relevant to the particular error he reported when starting this but report. But two others chimed in on this thread before I did with stack traces that potentially implicated JRebel ("com.zeroturnaround...") and the info that follows is potentially relevant to those contributors. I was previously running JRebel 6.0 and in certain debugging situations I would see this error two or three times a week. After contacting zeroturnaround and following their suggestion to pull down the latest nightly build (Feb 17 2015), I have yet to see a recurrence. The bug is sporadic enough that it's too early to claim victory, but I have 2.5 days on it now with no recurrences, so thought I'd share these findings with people who experience this bug when they have JRebel installed in Eclipse. For people who experience it for other reasons, sorry I couldn't help. For people looking for a way to reproduce it - installing JRebel 6.0.0. and then debugging in Eclipse might increase your chances of seeing it.
(In reply to Dan Smith from comment #20) > [...] After contacting > zeroturnaround and following their suggestion to pull down the latest > nightly build (Feb 17 2015), I have yet to see a recurrence. The bug is > sporadic enough that it's too early to claim victory, but I have 2.5 days on > it now with no recurrences, so thought I'd share these findings with people > who experience this bug when they have JRebel installed in Eclipse. Could you please provide the exact JRebel version of this nightly build that is in use? I use 6.0.3 Release and I get this Got MethodID Error quite often. Thanks in advance.
The JRebel Nightly Update build that I'm using is JRebel for Java EE 6.1.0.PREVIEW-201502171733. I have not seen a recurrence of the problem since I upgraded.
*** Bug 471395 has been marked as a duplicate of this bug. ***
I too think this was caused by JRebel, because it has been some time since I have seen it for the last time (meanwhile I've updated JRebel quite a few times).
I'm not using JRebel, and also uninstalled the JD-eclipse, and I have this problem for some sorts of conditional breakpoints. e.g. I've tried to add a aconditional breakpoint: Thread.currentThread().getId()==294L And all the threads stopped with the "Got MethodID..." error. I guess there is a source reason that might be concerned with many plugins? Something that all those plugins might be doing wrong that is causing this error?
This issue seems to be reproducible for folks at http://stackoverflow.com/questions/41146444/eclipse-conditional-breakpoint-doesnt-work (They're waiting for webmaster approval for commenting here ...)
Version: Oxygen.2 Release (4.7.2) Build id: 20171218-0600 I'm seeing this repeatedly while trying to debug a particular problem in my application. The breakpoint condition is very simple: id != null && id.equals("59") I don't see any stacktrace in the log, I just get an error dialog with the message cited in the ticket.
(In reply to David M. Karr from comment #27) > Version: Oxygen.2 Release (4.7.2) > Build id: 20171218-0600 > > I'm seeing this repeatedly while trying to debug a particular problem in my > application. > > The breakpoint condition is very simple: > > id != null && id.equals("59") > > I don't see any stacktrace in the log, I just get an error dialog with the > message cited in the ticket. can you attach a sample reproducible Project?
I'm seeing this when I try to add a condition to a breakpoint. I saw it frequently on previous versions of Eclipse too. Eclipse Oxygen.1a Release (4.7.1a) Windows 10 Pro v.1709 build 16299.125 java.version: 9.0.4 target JRE: Oracle jdk1.8.0_162
(In reply to Adrian Price from comment #29) > I'm seeing this when I try to add a condition to a breakpoint. I saw it > frequently on previous versions of Eclipse too. > > Eclipse Oxygen.1a Release (4.7.1a) > Windows 10 Pro v.1709 build 16299.125 > java.version: 9.0.4 > target JRE: Oracle jdk1.8.0_162 Sorry, the breakpoint condition in the latest instance was simply: "SomeString".equals(name) where name was a method parameter.
Just tried it on a freshly downloaded, pristine Eclipse Java Oxygen.2 (4.7.2) running on Oracle jdk1.8.0_162. A breakpoint with condition "Targets_v1".equals(fgParent.name) in a method private void FormGeneratorParamFactory.createChildren(StructuredType dataType, @Nullable DataAssociationConfig daConfig, FormGeneratorParam fgParent, Map<Object, FormGeneratorParam> fgParams, Map<String, Object> options) throws FormGeneratorException fails with the same error. In other words, conditional breakpoints NO LONGER WORK.
I was able to reproduce it (not all the time but about 2 out of 10). Steps to reproduce: - Create Java Project (I called it test) - Paste class from https://stackoverflow.com/q/41146444/2239897 - Place breakpoint as indicated in the code - Open Breakpoint properties and set the breakpoint to conditional with the condition being Boolean.TRUE.equals(b) - Debug As > Java Application Expected behavior: - All 100 Threads hit their breakpoints with no error Observed behavior: - in about 1 to 2 cases out of 10 (may be dependent on hardware configuration etc.) the popup error message "Got MethodID of ReferenceType that is not a member of the ReferenceType occurred retrieving stack frames" is displayed. I hope this helps in pinning down the problem, as I am also facing this issue from time to time.
(In reply to Stefan Winkler from comment #32) > I was able to reproduce it (not all the time but about 2 out of 10). Sorry, forgot my configuration: Windows 7 + Java 1.8.0_121 + Eclipse Oxygen.2 (4.7.2) Build id: M20171130-0510 org.eclipse.jdt.debug 3.11.50v20170920-1717 org.eclipse.jdt.debug.ui 3.8.51v20171031-0416
(In reply to Stefan Winkler from comment #33) > (In reply to Stefan Winkler from comment #32) > > I was able to reproduce it (not all the time but about 2 out of 10). > > Sorry, forgot my configuration: Windows 7 + Java 1.8.0_121 + Eclipse > Oxygen.2 (4.7.2) > Build id: M20171130-0510 > org.eclipse.jdt.debug 3.11.50v20170920-1717 > org.eclipse.jdt.debug.ui 3.8.51v20171031-0416 I have tried it now also with Photon M6 on the same machine and cannot reproduce this again :-(
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
