Community
Participate
Working Groups
I20050509-2010 I am able to produce timeout exceptions by stepping in a method while a logical structure is displayed for a Vector. Stepping quickly - allow the UI to start to update and then step again - seems to cause the problem. I am not holding down the step key. This may be flooding the target with requests as the views are attempting to update as the next step starts.
*** Bug 95707 has been marked as a duplicate of this bug. ***
It may be possible that multiple threads are waiting for a JDWP reply. When a reply packet is received a notifyAll() is performed in the receive manager which will let one thread check the reply packet queue. If the reply is not for the thread that was waiting, it goes into a wait again, but does not notify to allow another waiting thread to check the reply queue. By putting a notifyAll() before waiting for a packet, I no longer get timeout exceptions. This allows any other waiting threads to check the queue.
False lead - the notifyAll performed when a reply packet is received should have the desired effect of waking all waiting threads.
A few findings: * When invoking a method in the target VM to perform a 'toString()' or compute a logical structure, we set the request timeout to infinite. This has the side effect of causing other requests to the VM to use the infinite timeout as well (if the requests come in while performing the method invocation). We should only use the infinite timeout for methdod invocations. * The timeouts that are occurring are somewhere between 3 and 5 seconds on my machine. Increasing the timeout value reduces the occurrence of the problem. * method invocations seem pretty quick - usually less than 10ms on my machine * it appears that in my test case, ArrayReference.getValues() is timing out the most. * I can't get the problem to occurr on J9, only Sun VMs.
more notes: * I'm not sure why "array.getValues" is timing out * When I turn off logical structures and simply expand the raw list to show its array, the timeout does not occurr as often
*** Bug 94503 has been marked as a duplicate of this bug. ***
*** Bug 98550 has been marked as a duplicate of this bug. ***
Nothing planned for 3.1. We have no difinitive fixes. Note that the timeouts seem to occurr on the Sun VM, but not on the IBM/J9 VM.
Why didn't the timeout happen with older versions of Eclipse? Or did they?
Timeouts did occurr in older versions of Eclipse, but not as fequently (at least that's my impression). In 3.1, we do more work in background threads in the debugger which may put extra demands on the target (i.e. more requests coming from the front end at once). This may be the reason for the timeouts (but the problem needs more investigation). As well, it's not clear to me why the timeouts seem to occurr on Sun VMs, but not IBM VMs.
FYI, both IBM Sovereign and J9 VMs (at least have similar problem, they only fail faster so you do not obviously notice the failure. The exception that you get is !ENTRY org.eclipse.jdt.debug 4 120 2005-06-21 09:09:24.672 !MESSAGE Internal error logged from JDI Debug: !STACK 1 org.eclipse.debug.core.DebugException: Evaluation failed - thread not suspended. at org.eclipse.jdt.internal.debug.core.model.JDIDebugElement.throwDebugException(JDIDebugElement.java:200) at org.eclipse.jdt.internal.debug.core.model.JDIDebugElement.requestFailed(JDIDebugElement.java:158) at org.eclipse.jdt.internal.debug.core.model.JDIThread.runEvaluation(JDIThread.java:555) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTEvaluationEngine$EvalRunnable.run(ASTEvaluationEngine.java:389) at org.eclipse.jdt.internal.debug.core.model.JDIThread$ThreadJob.run(JDIThread.java:2446) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) !SUBENTRY 1 org.eclipse.jdt.debug 4 100 2005-06-21 09:09:24.672 !MESSAGE Evaluation failed - thread not suspended.
The failure in comment#11 is not a timeout - it shows an evaluation could not complete because a thread was not suspended. The same happens on Sun VMs.
Additional info - the problem appears to happen on my hyper-threaded P4 3GHz machine, but not my T30 laptop. As well, does not happen on Kevin's P4 2.6GHz machine either.
Great - so much for having a nice machine!
Created attachment 23670 [details] Patch allows to gather JDWP traffic info Attaching a patch I used to gather some JDWP traffic info. Patch is just to allow me to see what sort of messaging is going on with the target when a timeout occurrs. For my test case that causes the timeouts, I found we are usually retrieving many values from an array individually. A quick hack that coallesses the retrieval of values (100 at a time) makes the timeout problem disappear (however, my hack was not robust).
Created attachment 23787 [details] patch to measure thru put additional stat gathering code
We tested the hypothesis that we were flooding the VM with JDWP requests. The Sun VM seemed to peak at handling about 1350 requests per second, and J9 peaked at about 2800 requests per second. However, simply sending requests across the wire as fast as possible did not cause timeouts to occurr. Only when the requests were interleaved from different threads did the timeouts occurr. We then found that when we synchronized request sending with response receiving that the timeouts did not occurr. I.e. don't send request 2 until response 1 is received (or times out). I will attach a binary plug-in with the 'synch' behavior that users may test and provide feedback with.
Created attachment 23788 [details] zip of replacement org.eclipse.jdt.debug plug-in
Additional note - the fix is quite simple in terms of code. We only allow one thread to send and wait for a reply at once. There is only one place in our JDI client where this happens, so we can create a synchronized block around the send/receive on a global lock object. This still allows events to be received from the VM at the same time (so sending a request does not interfere with events being fired from the VM). To our knowledge, we don't know of any situation where one JDWP request relies on another to be sent at the same time (i.e. potential for deadlock).
Created attachment 23789 [details] Code patch for org.eclipse.jdt.debug
*** Bug 101430 has been marked as a duplicate of this bug. ***
I have a test case that floods a target from three separate threads for requests to get values from an array iteratively. The tests fail on Sun and J9 VMs without the synch fix. With the synch fix, all VMs pass the test. The strange thing is that the JDWP spec explicitly claims to be async: "The JDWP is asynchronous; multiple command packets may be sent before the first reply packet is received." In practice, this does not seem to be the case. I have modified my original patch to have one "communication" lock per VM rather than one communication lock for all VMs.
Targeting fix for 3.1.1. Synchronization change needs more testing in the field (too late/risky to put into 3.1).
Created attachment 23853 [details] patch Updated code patch that sync's per VM rather than for all VMs
Created attachment 23855 [details] Automated test (in progress) A test that can be used to flood a target. Starting point for adding a test to automated test suite.
I've been using the two patched versions of debug plugin for two days total and didn't see any timeout exceptions or any other problems. My vote is for including the fix in 3.1.
Created attachment 23975 [details] Test using jdi client directly Wrote a quick test that uses JDI directly instead of using Eclipse. Though JDI will not timeout like Eclipse does, I have not yet seen any unreasonable results from flooding the target this way (ie nothing approaching 3s). I've tested on Windows/Sun 1.4.2 and OS X/Apple 1.4.2. Notes: -code needs tools.jar/classes.jar to compile and run. -code cannot be run with eclipse's JDI client due to bug 101686
Created attachment 25416 [details] Project with stand alone JDI test Zip of project with standalone JDI test that shows problem. Test uses three threads to pound VM for values in an array. The VM appears to respond with intermittent delays (that cause timeouts using Eclipse JDI client). Problem occurss on P4 Hyper threaded machine with more fequency. Problem occurrs more fequently on Sun VM than IBM J9 VM.
Nothing planned for 3.1.1 as we have no difinitive fix available. Marking as 3.2.
Deferred. This problem occurrs less often using current 3.2 builds (perhaps because we use SWT.VIRTUAL trees, and create less labels/less requests on the target).
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
Reopening. I still see the odd one of these every now and again.
*** Bug 197294 has been marked as a duplicate of this bug. ***
*** Bug 408100 has been marked as a duplicate of this bug. ***
*** Bug 412220 has been marked as a duplicate of this bug. ***
Got a whole list of these on 3.8. No idea whether they still occur on 4.x... Still marked as NEW? Maybe set to CONFIRMED as there are so many people/duplicates?
Stacktrace in case it may help: org.eclipse.jdi.TimeoutException: Timeout occurred while waiting for packet 53815. at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:171) at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:180) at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:177) at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:208) at org.eclipse.jdi.internal.VirtualMachineImpl.classesBySignature(VirtualMachineImpl.java:599) at org.eclipse.jdi.internal.VirtualMachineImpl.classesByName(VirtualMachineImpl.java:626) at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.jdiClassesByName(JDIDebugTarget.java:1524) at org.eclipse.jdt.internal.debug.core.hcr.JavaHotCodeReplaceManager.filterUnloadedTypes(JavaHotCodeReplaceManager.java:338) at org.eclipse.jdt.internal.debug.core.hcr.JavaHotCodeReplaceManager.doHotCodeReplace(JavaHotCodeReplaceManager.java:434) at org.eclipse.jdt.internal.debug.core.hcr.JavaHotCodeReplaceManager.access$0(JavaHotCodeReplaceManager.java:421) at org.eclipse.jdt.internal.debug.core.hcr.JavaHotCodeReplaceManager$1.run(JavaHotCodeReplaceManager.java:310) at org.eclipse.debug.core.DebugPlugin$AsynchRunner.run(DebugPlugin.java:1078) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.debug.core.DebugPlugin$AsynchRunner.async(DebugPlugin.java:1061) at org.eclipse.debug.core.DebugPlugin$EventDispatchJob.run(DebugPlugin.java:413) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
(In reply to Stijn de Witt from comment #36) > Got a whole list of these on 3.8. No idea whether they still occur on 4.x... > Still marked as NEW? Maybe set to CONFIRMED as there are so many > people/duplicates? Thanks for the stacktrace, I have seen a couple of these in 4.x but not very often. > Still marked as NEW? Maybe set to CONFIRMED as there are so many > people/duplicates? Its still "new" because no committers are working on it (and there is no "confirmed" state)
*** Bug 461151 has been marked as a duplicate of this bug. ***
*** Bug 444603 has been marked as a duplicate of this bug. ***
*** Bug 462757 has been marked as a duplicate of this bug. ***
*** Bug 466898 has been marked as a duplicate of this bug. ***
*** Bug 466673 has been marked as a duplicate of this bug. ***
*** Bug 467369 has been marked as a duplicate of this bug. ***
*** Bug 467368 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/52978
(In reply to Eclipse Genie from comment #46) > New Gerrit change created: https://git.eclipse.org/r/52978 Bug 171075 comment 7 patch introduced the TimeoutException if the current thread is interrupted while waiting on packet. Interesting that the original version of the patch haven't this side effect, see bug 171075 comment 4. The proposal is to use original version of the patch, which does not throw TimeoutException if the current thread is interrupted. The reasoning is: the VirtualMachineImpl which creates "receiveThread" do not uses interrupt() to communicate cancellation or for any other reason. The possibility to interrupt waiting on the debuggee VM via <currentThread>.interrupt() in not documented and is not part of the public contract of PacketReceiveManager, it is only used internally. The internal use of interrupt() is in PacketManager.disconnectVM(), and the effect of call is not affected by this patch because the wait condition is evaluated to false via VMIsDisconnected() after this call. The only possible other callers of <currentThread>.interrupt() are outside of jdt debug, and they do if for different reasons as to stop waiting on reply from the debuggee VM. Therefore reacting on <currentThread>.interrupt() with TimeoutException causes unexpected side effects, as one can see for example in multiple duplicated bugs for bug 94452. Most of this bugs are side-effects of trying to interrupt current job thread or the hover computation thread of TextViewerHoverManager. Additionally, if the current thread is UI thread, it will be also interrupted by calling UISynchronizer.syncExec() from a non-UI thread. In all this cases we don't want to see TimeoutException, getReply() can probably finish successfully without exception (at least one can see it in the debugger). One also should notice, that interrupting a thread in getReply() do not interrupt actual debuggee execution task, which will still proceed, it will only let getReply() return before timeout occurs. Default timeout is 3000 ms, so in worst case the clients which do explicitly set timeout will wait 3 seconds more. In case clients set longer timeouts they usually do not want explicit thread termination (like JDIThread.invokeMethod() which is ready to wait as long as needed).
Thanks Andrey for the Contribution. @Mike, Can you review this change ?
I am able to provoke a timeout consistently. Eclipse Mars.1, Java 1.8.0_60, and a Tomcat 7.0 container. I'm willing to help in testing patches and/or collecting information.
(In reply to Jens Carlberg from comment #49) > I am able to provoke a timeout consistently. Eclipse Mars.1, Java 1.8.0_60, > and a Tomcat 7.0 container. I'm willing to help in testing patches and/or > collecting information. Jens, not sure if you can get 4.6 nightly SDK build and apply the patch over it: https://git.eclipse.org/r/52978? @JDT debug team: could you please make the build artifacts of this build: https://hudson.eclipse.org/platform/job/eclipse.jdt.debug-Gerrit/62/ accessible somewhere, so that people can try the patch out? I honestly have no idea how I can produce an Eclipse SDK build with the JDT patch applied to the 4.6 latest build state. Probably it would be good to allow gerrit instance to share build artifacts, similar how egit it does, see for example https://hudson.eclipse.org/egit/job/egit.gerrit/7743/ and the link on top to the build artifacts. In the gerrit job configuration you have to check "Archive the artifacts" checkbox and add there the path to the generated artifacts in target/repository/** directory. This way everyone can try out patch builds.
(In reply to Andrey Loskutov from comment #50) > > In the gerrit job configuration you have to check "Archive the artifacts" > checkbox and add there the path to the generated artifacts in > target/repository/** directory. This way everyone can try out patch builds. Hi Andrey, I have set the "Archive the artifacts" and added the path but it results to build failure. I guess the target/repository/ should pre exist. Adding David. @David, If you are aware , how to set it ?
(In reply to Sarika Sinha from comment #51) > (In reply to Andrey Loskutov from comment #50) > > > > In the gerrit job configuration you have to check "Archive the artifacts" > > checkbox and add there the path to the generated artifacts in > > target/repository/** directory. This way everyone can try out patch builds. > > Hi Andrey, > I have set the "Archive the artifacts" and added the path but it results to > build failure. I guess the target/repository/ should pre exist. Arrgh, sorry for wrong pointer, probably jdt repo has different build artifacts location as egit. I haven't expected this given the fact that maven usually enforces common rules where to place what.
(In reply to Sarika Sinha from comment #51) > Adding David. > @David, > If you are aware , how to set it ? I do not know, for the Gerrit jobs. You can probably see if its even created, though, by browsing through the 'workspace' of a job, right after it's built (and before next one starts, as 'workspace' is usually cleaned at the the start of a build). Then if it is created, that'd tell you how to 'archive' it. If not created ... hmm, not sure how to do that either, right off, for the Gerrit jobs in question.
Gerrit change https://git.eclipse.org/r/52978 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=68b1a4edb3b87fe0561fca4d22a41b6f98f56ba2
@Jens, patch has been delivered. Can you try the next nightly build of Neon to see if it fixes the problem.
(In reply to Sarika Sinha from comment #55) > @Jens, > patch has been delivered. Can you try the next nightly build of Neon to see > if it fixes the problem. Nope, no luck. I have tested two build for comparision, see below. Setup used in both tests ======================== * Tomcat 8.0.26 * JDK 1.8.0_60 * WAR-file deployed in Tomcat with application where I encounter the timeout * Windows 7 Enterprise SP-1 64bits, 16GRAM, CPU Intel i7-2600 * Workspace with the source code for the WAR-file * Chrome 46.0.2490.80 m (64-bit) * Workspace with the application I need to debug, complete with breakpoint where the timeout occurs. Tested builds ============= eclipse-SDK-N20151019-2000-win32-x86_64 eclipse-SDK-N20151021-2000-win32-x86_64 Testing steps for both builds ============================= * Start tomcat with jpda activated. * Start eclipse. * Goto debug perspective. * Connect to dt_socket:localhost:8765 (stored debug configuration). * In Chrome, surf to the application URL. * Eclipse hits the breakpoint 1st time. I hit Resume. * Eclipse hits the breakpoint 2nd time. I hit Resume. The timeout occurs. * Disconnect in Eclipse. Timeout occurs. * Chrome hangs, the Tomcat seems to not continue. * The Tomcat java process does not terminate through it's own shutdown script, the process have to be killed.
> Tested builds > ============= > eclipse-SDK-N20151019-2000-win32-x86_64 > eclipse-SDK-N20151021-2000-win32-x86_64 I have now also tested eclipse-SDK-N20151022-2000-win32-x86_64 with the same result.
(In reply to Jens Carlberg from comment #57) > > Tested builds > > ============= > > eclipse-SDK-N20151019-2000-win32-x86_64 > > eclipse-SDK-N20151021-2000-win32-x86_64 > > I have now also tested eclipse-SDK-N20151022-2000-win32-x86_64 with the same > result. Do you have stack trace with TimeoutException, or any errors in the Eclipse log?
Created attachment 257464 [details] Log file from run with build 20151019, 20151021, 20151022
I have attached the .metadata.log file from the workspace. It contains TimeoutExceptions for all three tested builds.
(In reply to Jens Carlberg from comment #60) > I have attached the .metadata.log file from the workspace. It contains > TimeoutExceptions for all three tested builds. Unfortunately your problem has probably a different root cause as one we've addressed with https://git.eclipse.org/r/52978. In your case the timeout exception is thrown on the jdt debug bundle shutdown (why???). org.eclipse.jdi.TimeoutException: Timeout occurred while waiting for packet 659. at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:193) at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:204) at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:192) at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:268) at org.eclipse.jdi.internal.VirtualMachineImpl.dispose(VirtualMachineImpl.java:692) at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.disconnect(JDIDebugTarget.java:789) at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.shutdown(JDIDebugTarget.java:1685) at org.eclipse.jdt.internal.debug.core.JDIDebugPlugin.stop(JDIDebugPlugin.java:349) at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:830) at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:1) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:823) at org.eclipse.osgi.internal.framework.EquinoxBundle.stopWorker0(EquinoxBundle.java:936) at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.stopWorker(EquinoxBundle.java:304) at org.eclipse.osgi.container.Module.doStop(Module.java:621) at org.eclipse.osgi.container.Module.stop(Module.java:483) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.decStartLevel(ModuleContainer.java:1623) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1542) at org.eclipse.osgi.container.SystemModule.stopWorker(SystemModule.java:248) at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.stopWorker(EquinoxBundle.java:137) at org.eclipse.osgi.container.Module.doStop(Module.java:621) at org.eclipse.osgi.container.Module.stop(Module.java:483) at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:186) at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:155)
Moving to M4 for further testing and analysis
It will be helpful if someone can try out and comment if recent patch has helped.
(In reply to Sarika Sinha from comment #63) > It will be helpful if someone can try out and comment if recent patch has > helped. It is not fair from me to answer (since I'm involved), but same patch applied on Eclipse 3.8.2 works nicely for our automated tests and since we applied the patch we haven't observed a single timeout exception. We run huge testsuite with various Eclipse tests ~60 times every day, with ~40 tests using debugger/breakpoint interaction and so directly affected by the change. Before the patch we had at least one (usually more) sporadic "Timeout" failure per day, and now they disappeared.
Resolving it have not received any related timeout exceptions. If some is able to reproduce please reopen.
I'm not sure what the bug fix process is for the Eclipse JDT but will this fix be back ported to Mars (4.5) and other recent releases? Or is there a plugin-patch I can pickup to use with Mars?
New Gerrit change created: https://git.eclipse.org/r/61958
(In reply to Eclipse Genie from comment #67) > New Gerrit change created: https://git.eclipse.org/r/61958 I've cherry picked the patch to the 4.5 maintenance branch. (In reply to Warwick Burrows from comment #66) > I'm not sure what the bug fix process is for the Eclipse JDT but will this > fix be back ported to Mars (4.5) and other recent releases? Or is there a > plugin-patch I can pickup to use with Mars? Now if we would want a backport to happen, we need: 1) +1 review from the developer 2) +1 for backport from component lead 3) this bug should be reopened and the target set to 4.5.2 @JDT Debug team: please decide if we want to backport this patch or not.
Thanks Andrey! Is it still possible to pickup nightly/stable builds of eclipse 4.5 maintenance releases like it is with eclipse projects? I haven't done this for the IDE in quite a while and right now I can't find the downloads page that would let me pickup a "nightly" or "stable" build of the next Mars maintenance release that would have your fix in it. (In reply to Andrey Loskutov from comment #68) > (In reply to Eclipse Genie from comment #67) > > New Gerrit change created: https://git.eclipse.org/r/61958 > > I've cherry picked the patch to the 4.5 maintenance branch. > > (In reply to Warwick Burrows from comment #66) > > I'm not sure what the bug fix process is for the Eclipse JDT but will this > > fix be back ported to Mars (4.5) and other recent releases? Or is there a > > plugin-patch I can pickup to use with Mars? > > Now if we would want a backport to happen, we need: > 1) +1 review from the developer > 2) +1 for backport from component lead > 3) this bug should be reopened and the target set to 4.5.2 > > @JDT Debug team: please decide if we want to backport this patch or not.
Sorry, ignore this I found the page so will watch for the next 4.5 build. (In reply to Warwick Burrows from comment #69) > Thanks Andrey! Is it still possible to pickup nightly/stable builds of > eclipse 4.5 maintenance releases like it is with eclipse projects? I > haven't done this for the IDE in quite a while and right now I can't find > the downloads page that would let me pickup a "nightly" or "stable" build of > the next Mars maintenance release that would have your fix in it. >
(In reply to Warwick Burrows from comment #70) > Sorry, ignore this I found the page so will watch for the next 4.5 build. Please note that decision to backport is not made, the review is not merged, so do not waste your CPU cycles watching the 4.5 maintenance nightly builds.
(In reply to Andrey Loskutov from comment #71) > (In reply to Warwick Burrows from comment #70) > > Sorry, ignore this I found the page so will watch for the next 4.5 build. > > Please note that decision to backport is not made, the review is not merged, > so do not waste your CPU cycles watching the 4.5 maintenance nightly builds. Oh ok, I misunderstood when you said: > I've cherry picked the patch to the 4.5 maintenance branch. It gave the impression that you had applied the cherry picked fix to the 4.5 branch already.
We are considering this for back porting to 4.5.2. Will like to wait for some more reviews from 4.6 M4 build.
I am still experiencing this issue under 4.6M4. I noticed that it happens to me only when the application creates a background thread that is separate from the thread that I'm debugging/breaking. When I disable the background thread I do not have the issue. Also, I'm experiencing it on Windows 7 Ultimate 64bit. My colleague debugs the same project on a Mac with no issues.
(In reply to Igal Sapir from comment #74) > I am still experiencing this issue under 4.6M4. > > I noticed that it happens to me only when the application creates a > background thread that is separate from the thread that I'm > debugging/breaking. When I disable the background thread I do not have the > issue. > > Also, I'm experiencing it on Windows 7 Ultimate 64bit. My colleague debugs > the same project on a Mac with no issues. This bug is closed. If you see it, then please file a new bug with exact steps to reproduce it.
