Howdy, Stranger!
We are about to switch to a new forum software. Until then we have removed the registration on this forum.
Categories
- All Categories 25.7K
- Announcements & Guidelines 13
- Common Questions 30
- Using Processing 22.1K
- Programming Questions 12.2K
- Questions about Code 6.4K
- How To... 4.2K
- Hello Processing 72
- GLSL / Shaders 292
- Library Questions 4K
- Hardware, Integration & Other Languages 2.7K
- Kinect 668
- Arduino 1K
- Raspberry PI 188
- Questions about Modes 2K
- Android Mode 1.3K
- JavaScript Mode 413
- Python Mode 205
- Questions about Tools 100
- Espanol 5
- Developing Processing 548
- Create & Announce Libraries 211
- Create & Announce Modes 19
- Create & Announce Tools 29
- Summer of Code 2018 93
- Rails Girls Summer of Code 2017 3
- Summer of Code 2017 49
- Summer of Code 2016 4
- Summer of Code 2015 40
- Summer of Code 2014 22
- p5.js 1.6K
- p5.js Programming Questions 947
- p5.js Library Questions 315
- p5.js Development Questions 31
- General 1.4K
- Events & Opportunities 288
- General Discussion 365
In this Discussion
- chrisjj January 2018
- jeremydouglass January 2018
- KevinWorkman January 2018
"Timeout occurred while waiting for packet 211" error from the IDE
Since I upgraded to 3.3.6 and denied Java access to networks, I get this error periodically in the IDE.
How can I prevent this, without granting Java access to networks? This is on Windows 7 64-bit.
org.eclipse.jdi.TimeoutException: Timeout occurred while waiting for packet 211. at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:187) at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:198) at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:192) at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:227) at org.eclipse.jdi.internal.VirtualMachineImpl.exit(VirtualMachineImpl.java:735) at processing.mode.java.runner.Runner.close(Runner.java:892) at processing.mode.java.JavaEditor.handleStop(JavaEditor.java:1129) at processing.mode.java.JavaEditor.internalCloseRunner(JavaEditor.java:1296) at processing.app.ui.Editor.prepareRun(Editor.java:2803) at processing.mode.java.JavaEditor.prepareRun(JavaEditor.java:1768) at processing.mode.java.JavaEditor.handleLaunch(JavaEditor.java:1086) at processing.mode.java.JavaEditor.handleRun(JavaEditor.java:1063) at processing.mode.java.JavaEditor$4.actionPerformed(JavaEditor.java:209) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.AbstractButton.doClick(AbstractButton.java:376) at javax.swing.AbstractButton.doClick(AbstractButton.java:356) at javax.swing.plaf.basic.BasicMenuItemUI$Actions.actionPerformed(BasicMenuItemUI.java:802) at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1663) at javax.swing.JComponent.processKeyBinding(JComponent.java:2882) at javax.swing.JMenuBar.processBindingForKeyStrokeRecursive(JMenuBar.java:699) at javax.swing.JMenuBar.processBindingForKeyStrokeRecursive(JMenuBar.java:706) at javax.swing.JMenuBar.processBindingForKeyStrokeRecursive(JMenuBar.java:706) at javax.swing.JMenuBar.processKeyBinding(JMenuBar.java:677) at javax.swing.KeyboardManager.fireBinding(KeyboardManager.java:307) at javax.swing.KeyboardManager.fireKeyboardAction(KeyboardManager.java:293) at javax.swing.JComponent.processKeyBindingsForAllComponents(JComponent.java:2974) at javax.swing.JComponent.processKeyBindings(JComponent.java:2966) at javax.swing.JComponent.processKeyEvent(JComponent.java:2845) at processing.app.syntax.JEditTextArea.processKeyEvent(JEditTextArea.java:1881) at processing.mode.java.pdex.JavaTextArea.processKeyEvent(JavaTextArea.java:145) at java.awt.Component.processEvent(Component.java:6310) at java.awt.Container.processEvent(Container.java:2236) at java.awt.Component.dispatchEventImpl(Component.java:4889) at java.awt.Container.dispatchEventImpl(Container.java:2294) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1954) at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:806) at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:1074) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:945) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:771) at java.awt.Component.dispatchEventImpl(Component.java:4760) at java.awt.Container.dispatchEventImpl(Container.java:2294) at java.awt.Window.dispatchEventImpl(Window.java:2746) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90) at java.awt.EventQueue$4.run(EventQueue.java:731) at java.awt.EventQueue$4.run(EventQueue.java:729) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Answers
This is probably just the IDE checking whether there's a new version. It's fine if this fails, and you can treat this as a warning and ignore it.
Thanks, but seems unlikely, since "Allow update checking" is unchecked.
Then please be more specific about exactly when you get this error.
Does this happen when you first open the editor? When you run a sketch? (Which one?) When you stop a sketch? Something else?
Does this error seem to interfere with anything, or is it just a warning?
I can say only it appears randomly, infrequently.
Not specifically when I open the IDE or run or stop a sketch.
My reading of the console.
Googling "org.eclipse.jdi.internal.VirtualMachineImpl" returns a bunch of results that help explain the issue, and googling "org.eclipse.jdi.internal.VirtualMachineImpl processing" returns this bug: https://github.com/processing/processing/issues/2623
Apparently this is not networking code at all. It's caused by a stack overflow in your code.
Thanks.
Can't see how. Unlike the example you posted, my code has no recursion.
And goodness knows why a stack overflow in my code would cause an exception in Eclipse.
There are other ways to cause a stack overflow that are not recursion -- for example, allocating or growing a very large stack variable.
Also keep in mind, there is no reason to play guess-all-the-different-things-it-could-be without providing actual code that could be used to reproduce your problem. That's not a good approach to debugging for anyone.
If the error is erratic and you are not confident that code can be used to reproduce your problem, consider different kinds of testing to isolate the issue -- for example, does the identical code do the same thing on a different computer? For related discussions, see:
I'm not sure what you are saying here. Are you asking why there is org.eclipse code in Processing PDE?
https://github.com/processing/processing/search?utf8=✓&q=org.eclipse&type=
Or are asking whether org.eclipse Java code and the Eclipse desktop application are the same thing? I can't tell.
I'm not doing that, anywhere I can see.
Agreed... if I could find a way to debug the run-time memory usage. Is there one? Even a display of the amount would be a good start.
It's good enough for me :) I'm not expecting anyone else to debug my code, and would not want to post the code.
No.
I wasn't asking anything :)
My "And goodness knows why a stack overflow in my code would cause an exception in Eclipse." was because I'd be surprised if my program and the IDE were that interdependent. I guess I'm wrong and in fact they are sharing the same JVM and hence stack+heap allocation.
Without more detail, it's going to be hard to help you further. I'd love to see a MCVE to check the behavior on my machines. If you don't feel like putting one together, that's fine, but there's probably not much more we can say then.
Yes, there are quite a few different ways to measure your memory use. From simple things like just printing it out, to more advanced tools that help you profile your code. I recommend googling "java measure memory usage" for a ton of results.
In any case, the error is caused by a stack overflow somewhere in your code, which can be caused by any number of things, not just recursion.
OK, so nothing in Processing then. Thanks.
I wonder what makes you think so. As opposed to heap usage. And/or in the Eclipse code.
Well, anything you can do in Java, you can do in Processing. So the memory measurement approach that works in Java (it's honestly just a few lines of code) will work in Processing.
What makes me think that is the results I posted in my reply. Other people have discussed this, and the consensus is that it's caused by a stack overflow. But again, anything we're saying is just a guess until we can see your code.
The consensus was that particular case was caused by a stack overflow ... in that old version. This new version has the fix https://github.com/processing/processing/pull/4152 and indeed here stack overflow (from e.g. recursion) does get reported as a stack overflow.
That discussion says " the StackOverflowError is sent, but for some reason a timeout occurs before it reaches the PDE.". The only part of that which is necessarily applicable to my case is "the error is sent, but for some reason a timeout occurs before it reaches the PDE."
We don't know what the error is, but stack overflow looks very unlikely.
Unless I find a easy way to narrow down the cause here, I'll try again on a future version hoping this case is fixed as was the stackoverflow case.
FTR I'm using thread().
Thanks.
Yep, like we've said, we can't really help in any more detail unless we see some example code. Good luck.