Community
Participate
Working Groups
What steps will reproduce the problem? 1. Debugging JEE application 2. Looking up objects in the Expression view or hovering over them shortly shows the values, then they get replaced by the exception (mostly large objects) There are no special steps or requirements, the exception occurs almost always. I already reinstalled Eclipse and have no plugins at the moment. When I press F6 and jump over to the next line the values shortly reappear but then get the same error again. -- Error Details -- Date: Wed Jul 25 13:05:31 CEST 2018 Message: com.sun.jdi.ObjectCollectedException occurred while retrieving value. Severity: Error Product: Eclipse IDE 4.8.0.20180619-1200 (org.eclipse.epp.package.jee.product) Plugin: org.eclipse.jdt.debug Session Data: eclipse.buildId=4.8.0.I20180611-0500 java.version=1.8.0_171 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE Framework arguments: -product org.eclipse.epp.package.jee.product Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product Exception Stack Trace: com.sun.jdi.ObjectCollectedException at org.eclipse.jdi.internal.MirrorImpl.defaultReplyErrorHandler(MirrorImpl.java:279) at org.eclipse.jdi.internal.ArrayReferenceImpl.getValues(ArrayReferenceImpl.java:131) at org.eclipse.jdi.internal.ArrayReferenceImpl.getValue(ArrayReferenceImpl.java:73) at org.eclipse.jdt.internal.debug.core.model.JDIArrayEntryVariable.retrieveValue(JDIArrayEntryVariable.java:87) at org.eclipse.jdt.internal.debug.core.model.JDIVariable.getCurrentValue(JDIVariable.java:72) at org.eclipse.jdt.internal.debug.core.model.JDIVariable.getValue(JDIVariable.java:96) at org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.computeLogicalStructureAdornmentFlags(JDIModelPresentation.java:1150) at org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.getVariableImage(JDIModelPresentation.java:925) at org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.getImage(JDIModelPresentation.java:693) at org.eclipse.debug.internal.ui.LazyModelPresentation.getImage(LazyModelPresentation.java:132) at org.eclipse.debug.internal.ui.DelegatingModelPresentation.getImage(DelegatingModelPresentation.java:146) at org.eclipse.debug.internal.ui.views.launch.DebugElementHelper.getImageDescriptor(DebugElementHelper.java:58) at org.eclipse.debug.internal.ui.model.elements.DebugElementLabelProvider.getImageDescriptor(DebugElementLabelProvider.java:79) at org.eclipse.debug.internal.ui.model.elements.VariableLabelProvider.getImageDescriptor(VariableLabelProvider.java:73) at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider.getImageDescriptor(ElementLabelProvider.java:292) at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider.retrieveLabel(ElementLabelProvider.java:219) at org.eclipse.jdt.internal.debug.ui.variables.JavaVariableLabelProvider.retrieveLabel(JavaVariableLabelProvider.java:183) at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelUpdater.run(ElementLabelProvider.java:165) at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelJob.run(ElementLabelProvider.java:74) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)
We're getting this as well with Eclipse 4.9 and JDK 11. Although the Eclipse version and JDK version are not the same as this, it also used to happen to us on Eclipse Photon and JDK 8. We have the exact same issue as the original reporter. When you're debugging a web application on tomcat, if you have a breakpoint set and try and expand a collection to view it's contents, you will receive the noted exception in 1-5 seconds. I found a suggestion in another older bug about disabling and re-enabling the breakpoint which does help us but still after ~30 seconds, the object in the debugger is collected. How can we prevent the object we are trying to inspect from being collected? From our point of view it can be extremely hard to debug code when you can't view the collection values. Non-collection data types don't seem to have the same issue. Only Lists and other collections.
Same problem as commenter in comment 1. This is issue renders the debugger unusable for us and blocks any further adoption of Eclipse 4.9.
(In reply to Christian Seiler from comment #2) > Same problem as commenter in comment 1. > This is issue renders the debugger unusable for us and blocks any further > adoption of Eclipse 4.9. Just curious if the 4.10 is also failing here? You can check M3 https://download.eclipse.org/eclipse/downloads/drops4/S-4.10M3-201811211800/. Question: I don't really understand what exact the problem is (I do not do any server work). So expanding the collection in the Variables shows the collection values for a short time (right), and then "they get replaced by the exception (mostly large objects)". What does it mean: the values are not shown anymore, and you see instead the error text there? Can you provide a screen shot? Another question: have you tried to disable "Show Logical Structure" button in the toolbar of the variables view? I believe this was enabled by default in 4.8.
Disabling the "Logical Structure" View works indeed! I.e within a running debugging session, in the Variables view, Right-Click on a Collection-type variable and remove any check mark
(In reply to Christian Seiler from comment #4) > Disabling the "Logical Structure" View works indeed! > I.e > within a running debugging session, > in the Variables view, > Right-Click on a Collection-type variable and remove any check mark Could you please attach a picture where it is *broken* please? The bug itself is probably an issue of too small heap size and debugger which relies on temporary objects to be kept in memory forever. I guess as soon as debugger "captured" the HUGE collection into an array, the reference to this object is probably collected by the GC (because it is a "hot spot" for the GC and no one except debugger used it, and I guess debugger does not hold a strong reference to it to avoid memory leaks), and the next time debugger tries to "decorate" the Variables view, it can't access originally evaluated data. So I guess another possible workaround would be to give more heap for the application server, so that GC doesn't kick off the objects too fast. @Sarika: can you point me to the place where the debugger logical structures are evaluated? I don't know how we manage the life cycle of evaluated structures. Either we should be able to recompute them on the fly if they got garbage collected, or we should add some strong reference to the VM objects, and release those references on leaving the frame or disconnecting the debugger. Just wondering if the same issue appears on the "usual" VM (not an application server at all), started with very small heap and with the code which creates something like a list of Integer.MAX_INT - 1 Double objects. Cloning this collection via debugger "logical" .toArray() code will double required heap size, and we should get same problem.
Created attachment 276701 [details] 1 - Variables View ArrayList with Structural View disabled Variables View ArrayList with Structural View disabled no element within the list is opened
Created attachment 276702 [details] 2 - Variables View ArrayList with Structural View disabled Variables View ArrayList with Structural View disabled first element of the list is opened
Created attachment 276703 [details] 3 - Variables View ArrayList with Structural View enabled Variables View ArrayList with Structural View enabled no element in the list is selected
Created attachment 276704 [details] 4 - Variables View ArrayList with Structural View enabled Variables View ArrayList with Structural View enabled after first element of the list was selected
(In reply to Andrey Loskutov from comment #5) > > @Sarika: can you point me to the place where the debugger logical structures > are evaluated? Lot of code is in Platform debug as well. In JDT you can check out the way it stores in map. org.eclipse.jdt.internal.debug.core.logicalstructures.JavaLogicalStructure org.eclipse.jdt.internal.debug.core.logicalstructures.JavaLogicalStructures Let me know if you were looking for something else.
I can get this error from a JUnit test, so application server and Java EE are not necessary to reproduce. What I have determined from investigation is that the Logical Structures code for Map/Collection is producing an array that is not referenced by anything else and so it is eligible for garbage collection. Once collected, the target program is returning invalid object errors.
*** Bug 540400 has been marked as a duplicate of this bug. ***
This has been reported in the past as 22309 and 32222.
(In reply to Eric Milles from comment #11) > I can get this error from a JUnit test, so application server and Java EE > are not necessary to reproduce. > > What I have determined from investigation is that the Logical Structures > code for Map/Collection is producing an array that is not referenced by > anything else and so it is eligible for garbage collection. Once collected, > the target program is returning invalid object errors. Please attach the test or even push a Gerrit with it.
Bug 33452 claims to fix that. Need to check in the code what was the fix and why it seem not working anymore (or in some cases).
Sorry, code under test is proprietary. Test calls service that returns a large JSON structure which is parsed to an object model. So there are large maps and lists in it. When browsing the logical structure, especially in the hover over a variable expression, the error occurs from time to time.
Is it possible to rewrite the logical structure for Collection to something besides "toArray()" so there would be a strong reference to what is returned?
For your interest. Maybe its helpful for you. When I switch OFF the button "Show Logical Structure" at the Debug-View, everything works fine. When I switch ON the button, I also get the ObjectCollectedException within my Collection (HashSet). Greetings from Germany. Alex K.
Oh sorry, you already know this. Shame on me.
(In reply to Eric Milles from comment #17) > Is it possible to rewrite the logical structure for Collection to something > besides "toArray()" so there would be a strong reference to what is returned? Yes, you can Add new logical structure definition for collection using Preferences->Java->Debug->Logical Structures
Just wanted to note that this happens for me and some colleagues from time to time, too. I'm using the "Logical Structure" view (the comments above seem to indicate this might be the root cause for the problem).
The same thing happens in eclipse 4.11
The same for eclipse 4.12
Just want to note that this happens even with sufficient main memory on small collections (in particular maps). I'm using 4.12.
Anything new here? I have this bug when i want to inspect lists (ArrayList) and maps (HashMap). This makes debugging very hard. This bug should be prioritized imho. eclipse.buildId=4.12.0.I20190605-1800 java.fullversion=11.0.4+11 JRE 11 Windows 10 amd64-64-Bit Compressed References 20190717_282 (JIT enabled, AOT enabled) OpenJ9 - 0f66c6431 OMR - ec782f26 JCL - fa49279450 based on jdk-11.0.4+11 BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE Command-line arguments: -os win32 -ws win32 -arch x86_64 org.eclipse.jdt.debug Error Wed Aug 28 07:38:17 CEST 2019 com.sun.jdi.ObjectCollectedException occurred while retrieving value. com.sun.jdi.ObjectCollectedException at org.eclipse.jdi.internal.MirrorImpl.defaultReplyErrorHandler(MirrorImpl.java:282) at org.eclipse.jdi.internal.ArrayReferenceImpl.getValues(ArrayReferenceImpl.java:134) at org.eclipse.jdi.internal.ArrayReferenceImpl.getValue(ArrayReferenceImpl.java:76) at org.eclipse.jdt.internal.debug.core.model.JDIArrayEntryVariable.retrieveValue(JDIArrayEntryVariable.java:90) at org.eclipse.jdt.internal.debug.core.model.JDIVariable.getCurrentValue(JDIVariable.java:75) at org.eclipse.jdt.internal.debug.core.model.JDIVariable.getValue(JDIVariable.java:99) at org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.computeLogicalStructureAdornmentFlags(JDIModelPresentation.java:1153) at org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.getVariableImage(JDIModelPresentation.java:928) at org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.getImage(JDIModelPresentation.java:696) at org.eclipse.debug.internal.ui.LazyModelPresentation.getImage(LazyModelPresentation.java:129) at org.eclipse.debug.internal.ui.DelegatingModelPresentation.getImage(DelegatingModelPresentation.java:140) at org.eclipse.debug.internal.ui.views.launch.DebugElementHelper.getImageDescriptor(DebugElementHelper.java:61) at org.eclipse.debug.internal.ui.model.elements.DebugElementLabelProvider.getImageDescriptor(DebugElementLabelProvider.java:82) at org.eclipse.debug.internal.ui.model.elements.VariableLabelProvider.getImageDescriptor(VariableLabelProvider.java:67) at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider.getImageDescriptor(ElementLabelProvider.java:274) at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider.retrieveLabel(ElementLabelProvider.java:201) at org.eclipse.jdt.internal.debug.ui.variables.JavaVariableLabelProvider.retrieveLabel(JavaVariableLabelProvider.java:186) at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelUpdater.run(ElementLabelProvider.java:147) at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelJob.run(ElementLabelProvider.java:74) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Can you attach Sample Project with exact steps for Eclipse SDK, I can not reproduce any error after Bug 543604 was fixed. @Simeon, Are you able to reproduce this?
(In reply to Eric Milles from comment #11) > I can get this error from a JUnit test, so application server and Java EE > are not necessary to reproduce. > > What I have determined from investigation is that the Logical Structures > code for Map/Collection is producing an array that is not referenced by > anything else and so it is eligible for garbage collection. Once collected, > the target program is returning invalid object errors. If this is the case, reproduction will not be simple. Maybe start a separate thread that creates junk and calls System.gc() every X milliseconds (250 maybe for a main() mini-example). Then we'll need a GC strategy that actually complies to the System.gc() call, I recall Java 11 having something like that. In our products debugger, we call org.eclipse.jdt.debug.core.IJavaObject.disableCollection() on values we create as long as they are used, and at the end of their life cycle we call org.eclipse.jdt.debug.core.IJavaObject.enableCollection(). Does JDT do this also Sarika? Grepping for "disableCollection" in org.eclipse.jdt.debug/model/org/eclipse/jdt/internal/debug/core/logicalstructures yields nothing, so probably not? We had a number of ObjectCollectedException sporadic exceptions during our debug tests due to forgotten disableCollection() calls here and there. Maybe the below stack trace can also occur if you resume the JVM with very bad timing, though I don't know about this (would have to be really really unfortunate timing?). Looking at the description, this shouldn't be the case. com.sun.jdi.ObjectCollectedException at org.eclipse.jdi.internal.MirrorImpl.defaultReplyErrorHandler(MirrorImpl.java:282) at org.eclipse.jdi.internal.ArrayReferenceImpl.getValues(ArrayReferenceImpl.java:134) at org.eclipse.jdi.internal.ArrayReferenceImpl.getValue(ArrayReferenceImpl.java:76) at org.eclipse.jdt.internal.debug.core.model.JDIArrayEntryVariable.retrieveValue(JDIArrayEntryVariable.java:90) at org.eclipse.jdt.internal.debug.core.model.JDIVariable.getCurrentValue(JDIVariable.java:75) at org.eclipse.jdt.internal.debug.core.model.JDIVariable.getValue(JDIVariable.java:99) at org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.computeLogicalStructureAdornmentFlags(JDIModelPresentation.java:1153) at org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.getVariableImage(JDIModelPresentation.java:928) at org.eclipse.jdt.internal.debug.ui.JDIModelPresentation.getImage(JDIModelPresentation.java:696) at org.eclipse.debug.internal.ui.LazyModelPresentation.getImage(LazyModelPresentation.java:129) at org.eclipse.debug.internal.ui.DelegatingModelPresentation.getImage(DelegatingModelPresentation.java:140) at org.eclipse.debug.internal.ui.views.launch.DebugElementHelper.getImageDescriptor(DebugElementHelper.java:61) at org.eclipse.debug.internal.ui.model.elements.DebugElementLabelProvider.getImageDescriptor(DebugElementLabelProvider.java:82) at org.eclipse.debug.internal.ui.model.elements.VariableLabelProvider.getImageDescriptor(VariableLabelProvider.java:67) at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider.getImageDescriptor(ElementLabelProvider.java:274) at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider.retrieveLabel(ElementLabelProvider.java:201) at org.eclipse.jdt.internal.debug.ui.variables.JavaVariableLabelProvider.retrieveLabel(JavaVariableLabelProvider.java:186) at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelUpdater.run(ElementLabelProvider.java:147) at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelJob.run(ElementLabelProvider.java:74) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Andrey, should I take a look here? Right now my hands are kind of full as you are on vacation.
(In reply to Simeon Andreev from comment #27) > > In our products debugger, we call > org.eclipse.jdt.debug.core.IJavaObject.disableCollection() on values we > create as long as they are used, and at the end of their life cycle we call > org.eclipse.jdt.debug.core.IJavaObject.enableCollection(). Does JDT do this > also Sarika? Grepping for "disableCollection" in > org.eclipse.jdt.debug/model/org/eclipse/jdt/internal/debug/core/ > logicalstructures yields nothing, so probably not? We had a number of > ObjectCollectedException sporadic exceptions during our debug tests due to > forgotten disableCollection() calls here and there. > Grepping gives me these results- org.eclipse.jdt.internal.debug.eval.ast.engine.AbstractRuntimeContext org.eclipse.jdt.internal.debug.eval.ast.engine.Interpreter org.eclipse.jdt.internal.debug.core.logicalstructures.LogicalObjectStructureValue
Reproduced also under Ubuntu 18.04, Eclipse 4.13, openjdk 11.0.4 2019-07-16 I'm running a simple Java application, nothing fancy. The list which I try to visualize is a simple array list that is for sure in memory and cannot be physically collected since it is manipulated on many lines after the breaking point. Side note: Eclipse debugging is useless since many years. Last known version where I remember it working was 3.7. I end up adding logging in console. I always use the latest version in the hope of debugger being finally fixed but I'm losing patience... I'm afraid I'd reach retirement age and still not see the debugger fixed.
(In reply to Sergiu Hlihor from comment #29) > Reproduced also under Ubuntu 18.04, Eclipse 4.13, openjdk 11.0.4 2019-07-16 > > I'm running a simple Java application, nothing fancy. The list which I try > to visualize is a simple array list that is for sure in memory and cannot be > physically collected since it is manipulated on many lines after the > breaking point. > > > Side note: Eclipse debugging is useless since many years. Last known version > where I remember it working was 3.7. I end up adding logging in console. I > always use the latest version in the hope of debugger being finally fixed > but I'm losing patience... I'm afraid I'd reach retirement age and still not > see the debugger fixed. Can you try the same thing in Eclipse 4.13 Platform SDK with similar configuration? We need to isolate if it is Java Debugging issue or from some other layer?
(In reply to Sergiu Hlihor from comment #29) > Reproduced also under Ubuntu 18.04, Eclipse 4.13, openjdk 11.0.4 2019-07-16 > > I'm running a simple Java application, nothing fancy. The list which I try > to visualize is a simple array list that is for sure in memory and cannot be > physically collected since it is manipulated on many lines after the > breaking point. If this is simple Java application, and reproducible failing since years, could you please try to isolate a standalone example that you could share here? > Side note: Eclipse debugging is useless since many years. Last known version > where I remember it working was 3.7. I end up adding logging in console. I > always use the latest version in the hope of debugger being finally fixed > but I'm losing patience... I'm afraid I'd reach retirement age and still not > see the debugger fixed. Side note: using Eclipse debugger since 2002, *never ever* seen the problems here, working with lot of different simple and not so simple Java applications, never needed console for debugging. I always use the latest version & I hope I'd reach retirement age and still see the debugger working.
(In reply to Sarika Sinha from comment #30) > Can you try the same thing in Eclipse 4.13 Platform SDK with similar > configuration? > We need to isolate if it is Java Debugging issue or from some other layer? I was using "Eclipse IDE for Enterprise Java Developers", with only SonarLint and Scala plugins installed extra. As mentioned, envionment is Ubuntu 18.04 and I strongly suspect it is somehow related as coincidentally when I switch from 3.7 I also switched to using Ubuntu. Some notes, issue happens not immediately but after a period of idle time. For example, I'm reaching the line, then start to inspect and after 2-3 minutes if I click on variable, output is gone. Yesterday I lost over half an hour of debugging, all because this actually was reproducible reliably.
> Side note: using Eclipse debugger since 2002, *never ever* seen the problems > here, working with lot of different simple and not so simple Java > applications, never needed console for debugging. I always use the latest > version & I hope I'd reach retirement age and still see the debugger working. Don't want to start a flame here but you sound just like me when I talk about Windows Millenium. Used that OS without any problem for 3 years praising how good it is, without even knowning that world wide it was viewed as one of the worst OSes. Some other issues that I am confronted daily is debugger freezing for 20+ seconds when I step over a method that does class loading. My workaround is to always add a breaking point to next line and press "play" which is way faster. Since I deeply dislike the "intelligent" alternative to Eclipse, I'm more that happy to contribute with bug reports if someone is willing to actually fix the bugs.
(In reply to Sergiu Hlihor from comment #33) > Some other issues that I am confronted daily is debugger freezing for 20+ > seconds when I step over a method that does class loading. My workaround is > to always add a breaking point to next line and press "play" which is way > faster. Since I deeply dislike the "intelligent" alternative to Eclipse, I'm > more that happy to contribute with bug reports if someone is willing to > actually fix the bugs. Could be bug 533702.
(In reply to Sergiu Hlihor from comment #32) > (In reply to Sarika Sinha from comment #30) > > Can you try the same thing in Eclipse 4.13 Platform SDK with similar > > configuration? > > We need to isolate if it is Java Debugging issue or from some other layer? > > I was using "Eclipse IDE for Enterprise Java Developers", with only > SonarLint and Scala plugins installed extra. As mentioned, envionment is > Ubuntu 18.04 and I strongly suspect it is somehow related as coincidentally > when I switch from 3.7 I also switched to using Ubuntu. > > Some notes, issue happens not immediately but after a period of idle time. > For example, I'm reaching the line, then start to inspect and after 2-3 > minutes if I click on variable, output is gone. Yesterday I lost over half > an hour of debugging, all because this actually was reproducible reliably. I will again ask you you to try in Platform SDK, as we have not seen this. For slowness, Can you try disabling the Preferences->Java->Debug Show method result after a step operation
(In reply to Sarika Sinha from comment #35) > (In reply to Sergiu Hlihor from comment #32) > > (In reply to Sarika Sinha from comment #30) > > > Can you try the same thing in Eclipse 4.13 Platform SDK with similar > > > configuration? > > > We need to isolate if it is Java Debugging issue or from some other layer? > > > > I was using "Eclipse IDE for Enterprise Java Developers", with only > > SonarLint and Scala plugins installed extra. As mentioned, envionment is > > Ubuntu 18.04 and I strongly suspect it is somehow related as coincidentally > > when I switch from 3.7 I also switched to using Ubuntu. > > > > Some notes, issue happens not immediately but after a period of idle time. > > For example, I'm reaching the line, then start to inspect and after 2-3 > > minutes if I click on variable, output is gone. Yesterday I lost over half > > an hour of debugging, all because this actually was reproducible reliably. > > I will again ask you you to try in Platform SDK, as we have not seen this. > > For slowness, Can you try disabling the Preferences->Java->Debug > Show method result after a step operation I started tracking this issue as I'm getting this now with 2019-06 but proceeding so far by disabling "Show Logical Structure" that allows me to work. Like others this is intermittent and I have figured out the pattern, but here also will get results on a few items in the collection and then it starts failing.
(In reply to Alain Picard from comment #36) > > I started tracking this issue as I'm getting this now with 2019-06 but > proceeding so far by disabling "Show Logical Structure" that allows me to > work. Like others this is intermittent and I have figured out the pattern, > but here also will get results on a few items in the collection and then it > starts failing. Can you detail the pattern ? It will help us to reproduce. If we cannot reproduce, we can not help !
I can reproduce it with (it does not happen without the timer task to gc: import java.util.Arrays; import java.util.List; import java.util.Timer; import java.util.TimerTask; public class EclipseDebugCollected { public static void main(String[] args) { Timer timer = new Timer(); timer.scheduleAtFixedRate(new TimerTask() { private List<String> garbage; @Override public void run() { System.gc(); garbage = Arrays.asList(new String("a"), new String("b"), new String("c")); } }, 250, 250); List<String> someData = Arrays.asList(new String("a"), new String("b"), new String("c")); // set on next line, looks and expand someData, then it elements, com.sun.jdi.ObjectCollectedException occurred while retrieving value System.out.println(someData); } } Using: Eclipse IDE for Java Developers Version: 2019-12 (4.14.0) Build id: 20191212-1212 Changes to eclipse.ini (setting vm enables taskbar grouping in Windows): -vm C:/Program Files/AdoptOpenJDK/jdk-11.0.6.10-hotspot/bin -Xms256m -Xmx4G (the GC is default, not changed but for clarity) -XX:+UseG1GC -XX:+UseStringDeduplication openjdk version "11.0.6" 2020-01-14 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode) Microsoft Windows [Version 10.0.18363.592]
(In reply to Walter Laan from comment #38) > I can reproduce it with (it does not happen without the timer task to gc: > Thanks! I am to reproduce the issue.
Hi, I am experiencing the problem recently. Our project is very big. Classes and Objects hierarchy is quite complex. So when I want to check an object's value in a deep structure, it happens and stops me from inspecting the values within an object. It happens in 'Inspect', 'variables' and 'Expressions'. Since I am checking deep objects, I am not sure if the deep structure or the time is affecting. Anyway, I guess when Eclipse uses a lot of memory, for my case, 8G, and when the object that is being inspected is big as well, it reproduces easily. Thanks to Community, disabling 'Show Logical Structure' in 'Variables' view solves this so far. All the three places are working now, 'Inspect', 'Variables' and 'Expression'. Thank you
Anyone can step in to work on this?
I can confirm that this bug still exists in 2020-06 (4.16.0).
When everyone says to "disable Logical Structures", does that mean I need to remove all of the entries shown in the Logical Structures list under the Preferences dialog (Java > Debug > Logical Structures)? The 5 default entries cannot be removed in those list, yet I'm still experiencing ObjectCollectedException when viewing them. If only they can be "toggled" to enabled or disabled, so certain logical structures won't apply when viewing / inspecting them via the Debugger in the Expressions / Variables tabs. The way I reproduce this error is by: 1. In the Preferences dialog, navigate to (Java > Debug > Detail Formatters). 2. Add an entry for: "java.lang.Integer". 3. In the code snippet, add the following (no "return" keywords): this.toString() + " [" + String.format("%08X", this.value) + "]"; 4. "Save", and then "Apply and Close". 5. Debug a simple Java application where you are able to instantiate an Integer object. 6. Add the Integer object to the Expressions tab. 7. Add a math arithmetic statement to the Expressions tab. 7. Click and repeatedly click on the Integer object and the other statement back and forth until you encounter the ObjectCollectedException error.
(In reply to Taro Kyo from comment #43) > When everyone says to "disable Logical Structures", does that mean I need to > remove all of the entries shown in the Logical Structures list under the > Preferences dialog (Java > Debug > Logical Structures)? > By disabling, it means toggle the button to "off" state and hence not use the Detail formatters. Some people are not so interested in "Detail Formatters" but "Show Logical Structures" button is witched "on" by default, so in those cases it can be disabled. But if you want to see Logical Structures, we don't have a workaround/solution yet.
(In reply to Sarika Sinha from comment #41) > Anyone can step in to work on this? I just had the issue myself. The XML DOM Element structure gets recreated very frequently while shown in variables view. -> the ids of the Node[] arrays for children and attributes change rapidly while in breakpoint. I'm willing to help, but need some guidance. Looks like disableCollection is called on the result by Interpreter::push, but after execution, releaseObjects() will enable collection on all objects again - including the evaluation result on top of the stack. By the time the result arrives in JavaLogicalStructure::getLogicalStructure, the value may already been collected (especially while debugging the debugger). Seems to me that the Interpreter needs to keep collection disabled for the result (in this scenario anyway). But: how will it be enabled again? The result is cached by eclipse.debug.ui in LogicalStructureCache, so it must stay alive until LogicalStructureCache::clear is called. That looks like the correct place for reenabling collection: > Cache should be cleared when a RESUME or TERMINATE event is fired so the > structure can be reevaluated for new values. But then we'd need an API like ILogicalStructureTypeDelegate3 { void releaseValue(IValue value); } Sarika, Andrey WDYT?
(In reply to Julian Honnen from comment #45) > (In reply to Sarika Sinha from comment #41) > > Anyone can step in to work on this? > I just had the issue myself. The XML DOM Element structure gets recreated > very frequently while shown in variables view. > -> the ids of the Node[] arrays for children and attributes change rapidly > while in breakpoint. > > > I'm willing to help, but need some guidance. > Looks like disableCollection is called on the result by Interpreter::push, > but after execution, releaseObjects() will enable collection on all objects > again - including the evaluation result on top of the stack. > > By the time the result arrives in JavaLogicalStructure::getLogicalStructure, > the value may already been collected (especially while debugging the > debugger). > > Seems to me that the Interpreter needs to keep collection disabled for the > result (in this scenario anyway). > But: how will it be enabled again? What do you mean by keep disabled and enable again? > > The result is cached by eclipse.debug.ui in LogicalStructureCache, so it > must stay alive until LogicalStructureCache::clear is called. > That looks like the correct place for reenabling collection: > > Cache should be cleared when a RESUME or TERMINATE event is fired so the > > structure can be reevaluated for new values. > > But then we'd need an API like > ILogicalStructureTypeDelegate3 { > void releaseValue(IValue value); > } We can add default method to avoid creating new interface. > > Sarika, Andrey WDYT?
(In reply to Sarika Sinha from comment #46) > What do you mean by keep disabled and enable again? Interpreter::releaseObjects should not call enableCollection() on the object(s) that are returned from Interpreter::getResult The caller then is responsible for calling enableCollection() on the result to release it. > We can add default method to avoid creating new interface. Adding a default method is still an API breaking change. Add default method If interface not implementable by Clients Binary compatible If interface implementable by Clients Breaks compatibility (8) https://wiki.eclipse.org/Evolving_Java-based_APIs_2
(In reply to Julian Honnen from comment #47) > (In reply to Sarika Sinha from comment #46) > > What do you mean by keep disabled and enable again? > Interpreter::releaseObjects should not call enableCollection() on the > object(s) that are returned from Interpreter::getResult > > The caller then is responsible for calling enableCollection() on the result > to release it. > > org.eclipse.jdt.debug.core.IJavaObject.enableCollection() is an API and we cannot change the behaviour as it might be already being used with assumption that enableCollection() will be called. > > We can add default method to avoid creating new interface. > Adding a default method is still an API breaking change. > > Add default method > If interface not implementable by Clients Binary compatible > If interface implementable by Clients Breaks compatibility (8) > https://wiki.eclipse.org/Evolving_Java-based_APIs_2 Yes, it breaks only if the client had the method with the same name which we don't expect. Otherwise we can never take advantage of default Interface methods.
(In reply to Sarika Sinha from comment #48) > org.eclipse.jdt.debug.core.IJavaObject.enableCollection() is an API and we > cannot change the behaviour as it might be already being used with > assumption that enableCollection() will be called. I don't want to change the behavior of IJavaObject. I want to change Interpreter, so that it doesn't enable collection on the returned objects. > Yes, it breaks only if the client had the method with the same name which we > don't expect. Otherwise we can never take advantage of default Interface > methods. I agree completely, but in the past I had changes rejected because of that. I'll submit an prototype gerrit.
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.debug/+/167473
*** Bug 566342 has been marked as a duplicate of this bug. ***
I am also affected by this bug and it makes the debugger almost unusable for me. If there is a patch in progress I'm willing to manually try it out.
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.debug/+/167473 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=a03cb8e29665af02798f434a167338a1826e51cb
Thanks Julain for taking this up, this will help a lot of people! Please add a N&N entry.
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/172277
(In reply to Sarika Sinha from comment #54) > Thanks Julain for taking this up, this will help a lot of people! Big thanks from me, too.
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/172277 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=4028b5581fdaf07ddeb635d34c6b1ca48144cf74
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.debug/+/172363 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=34354d1ea04ef7d113975754fd82ee9d15d0a488
New test fails randomly with ObjectCollectedException, see bug 569157.
I am using Eclipse 2021-03 (4.19.0) and I'm still seeing this issue quite frequently.
(In reply to Chin Bim from comment #60) > I am using Eclipse 2021-03 (4.19.0) and I'm still seeing this issue quite > frequently. Can you provide a sample testcase?
Here, very similar to to example posted elsewhere in this thread except I use Guava's ImmutableList: import java.util.Arrays; import java.util.List; import java.util.Timer; import java.util.TimerTask; import com.google.common.collect.ImmutableList; public class EclipseDebugCollected { public static void main(String[] args) { Timer timer = new Timer(); timer.scheduleAtFixedRate(new TimerTask() { private List<String> garbage; @Override public void run() { System.gc(); garbage = Arrays.asList(new String("a"), new String("b"), new String("c")); } }, 250, 250); List<String> someData = ImmutableList.of(new String("a"), new String("b"), new String("c")); // set on next line, looks and expand someData, then it elements, com.sun.jdi.ObjectCollectedException occurred while retrieving value System.out.println(someData); } } It doesn't happen 100% of the time but fairly often.
Here is the screenshot: https://i.imgur.com/2Ds8t9p.png Using AdoptOpenJDK 8.0.232 Windows 10 Eclipse Version: 2021-03 (4.19.0) Build id: 20210312-0638
@Julian, Can you please create a follow up bug and look into it?
(In reply to Sarika Sinha from comment #64) > @Julian, > Can you please create a follow up bug and look into it? I assume this hits the same inherent limitation as our own testcase did, see bug 569157 comment 1.
