Community
Participate
Working Groups
20020402 (has been broken since at least 0214, maybe earlier) This has been broken for quite a while - I kept thinking it was so obviously broken that someone would surely fix it, but I have figured out that it is probably only a problem with standalone SWT examples... so I am finally opening this PR because all of us on the SWT team hit this every time we debug. Here are the steps required to run a little SWT class in eclipse: 1) Connect to the dev.eclipse.org repository 2) Open HEAD 3) Turn off autobuild (important) 4) Select the org.eclipse.swt project 5) Select "Check out as project" from the pop-up menu 6) Go to a Packages view 7) In the view menu (little black triangle), select "Filters..." 8) Make sure that ".*" is NOT checked (i.e. you need to see "." files) 9) Click OK 10) Now expand org.eclipse.swt 11) Select the file ".classpath_win32" (assuming you are working on Windows) 12) Rename this file to ".classpath" 13) Workbench -> Rebuild All 14) Now it is safe to turn autobuild back on 15) Now you need to put the swt dll somewhere where the VM can find it. What we do is export it to the 'eclipse' directory, which will be the current directory. To do this, do the following (assuming Windows): - In the Packages view, expand org.eclipse.swt/os/win32/x86 - Select the dll file - File -> Export -- File system -- Next> - In the "Directory" field, select your 'eclipse' directory - Finish You only have to do the above 15 steps once (per workspace...<g>). 16) Now paste the following little class into a test project where you can run Java code: import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; public class SWTTest { static Display display; static Shell shell; static List list; public static void main(String[] args) { display = new Display(); shell = new Shell(display); shell.setLayout(new GridLayout()); shell.setText("List Test"); list = new List(shell, SWT.MULTI); list.setLayoutData(new GridData(GridData.FILL_BOTH)); for (int i = 0; i < 5; i++) { list.add("item" + i); } shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } } } 17) Put a breakpoint on any valid line of code (I have mine on shell.setText...) 18) Run under the debugger Here's the bug: When you hit the breakpoint, the debugger bogusly opens up an editor on "ClassLoader.class", and the stack looks like garbage (as if it was stuck on the first line of code in the loadLibrary call, but we are actually way past that call by the time we hit the breakpoint). I will paste the garbage stack at the end of this description. The only way to actually debug your code is to do one "step over". Unfortunately, you will then be past the line where you set your breakpoint. This is *not* a "stop-ship" type problem for us - it's just really annoying. (Also annoying is having to close the empty "ClassLoader.class" editor all the time <g>). Thread [main] (Suspended (breakpoint at line 16 in test.SWTTest)) java.lang.ClassLoader.loadLibrary0(java.lang.Class, java.io.File) line: 1470 [local variables unavailable] java.lang.ClassLoader.loadLibrary(java.lang.Class, java.lang.String, boolean) line: 1346 <not responding> java.lang.System.loadLibrary(java.lang.String) line: 849 org.eclipse.swt.internal.Library.loadLibrary(java.lang.String) line: 102 org.eclipse.swt.internal.win32.OS.<clinit>() line: 39 <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> test.SWTTest.main(java.lang.String[]) line: 13
I followed the steps exactly (and they are very well written, I might add), but got the expected behavior: SWTTest at localhost:14043 System Thread [Finalizer] (Running) System Thread [Reference Handler] (Running) Thread [main] (Suspended (breakpoint at line 14 in SWTTest)) SWTTest.main(java.lang.String[]) line: 14 System Thread [Signal Dispatcher] (Running) System Thread [CompileThread0] (Running)
Which VM do you run your example program on? I tried Sun 1.4.1, 1.3.1_01 and IBM 1.3 - but they all worked.
IBM 1.3. Specifically: C:\Eclipse\dev\eclipse\jre\bin>.\java -showversion java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cn130-20010502 (JIT enabled: jitc) ) I just tried it here at home in 20020404 on Win98 - same wierd result, same strange stack trace. At work, I run on Win2K. Probably the same VM, but when I get to work tomorrow I'll look to make sure. SN and VI have the same problem. I wonder what the difference is between your setup and ours. I'm running javaw, if that makes any difference. Also, I run with -data pointing to my workspace directory, and so does VI, but I know SN just uses the default workspace. I will ask the remaining members of the SWT team to see if everyone actually does have the problem. If it's only some of us, I will see if I can find some correlation.
I just tried Carolyn's test case on my WinXP box. Same VM as her. I did *not* see the problem.
More info from the SWT team: My VM at work is the same as at home: java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cn130-20010502 (JIT enabled: jitc) ) McQ does not see this (running on XP). He is running the same VM as I am (IBM 1.3). SR says the following: "I have had this problem before, but I cannot consistently reproduce it. I tried to this morning using your steps and could not." GG says: "I see this as well, both on my machine regularly and on Filipe's yesterday. We were both running Linux."
I have this same problem every often (almost always) in my Eclipse-Motif. I guess I'm living with this problem for more than one month.
I've seen this a while ago, but not in quite some time. Try it on J9. Switching to J9 may have fixed it for me.
Completely fresh workspace, everything from scratch, same problem. I used the same VM (IBM 1.3.0) - now I will try it with the IBM 1.3.1 VM.
IBM 1.3.1 VM - same problem. I'll try Sun 1.3.1.
Interesting: I do *not* have the problem with Sun 1.3.1. (But I did have it with IBM 1.3.1). What is odd is that McQ and Chris *do not* have the problem with IBM 1.3.0. And Shantha does not have the problem on IBM 1.3.0 (but she has seen it). But Grant, Felipe, Veronika, and I *do* have the problem with IBM 1.3.0. Silenio *does* have the problem on Photon with J9 and on Linux with IBM 1.3.0. Any other suggestions for things to try?
For what it's worth, I get the exact same problem when running JDT Core stand-alone test suites. These are run in a JUnit SWT test runner application. I am using build 20020426, and IBM JRE 1.3.0 (cn130-20010502) on Win2K. In my case it gets hung up while loading a different library (the org.eclipse.core.resources library), but all other symptoms are the same. A workspace can be supplied if needed.
Thanks, John. Sort of feels like a more "valid" problem if another team sees it also. <g> The only way I personally could make the problem go away is to use Sun's 1.3.1 VM. But that can't be the only cure, because it appears to be a cross-VM, cross-platform problem. i.e. we have seen it on multiple IBM VMs, we have seen it on J9, we have seen it on multiple Windows platforms, and we have seen it on Linux and Photon. It happens every time. Until you change "something" in your setup (unfortunately, we don't know what).
*** Bug 15204 has been marked as a duplicate of this bug. ***
*** Bug 15153 has been marked as a duplicate of this bug. ***
It's almost certainly a timing issue, which explains why some people seem to see it on some VMs and some on others. No luck reproducing the problem yet, but I have a working theory. If I can't reproduce the problem in the next 24 hours (I can't get the SWT example to run at all on motif), I'll be sending Carolyn a patch to test the current theory.
I can run the example now, but I'm not seeing the exact problem you reported. On the IBM 1.3.1 VM I am seeing one of the threads flash a bunch of stack frames for a moment when it's created, but the main thread hits the breakpoint at the correct location. Is there a VM that produces this problem consistently? Do you get the problem 100% of the time?
I think I see the weird stack trace and wrong break location *all* the time whenever I hit a break point for the first time while debugging an inner Eclipse on the 20020206 J9 VM. Not sure if it always happens with a recent 2.0 VM.
I have the problem 100% of the time on the first breakpoint of every debug launch of a standalone SWT app. i.e. the first time a class with a breakpoint is loaded, the debugger stops in the ClassLoader class and the stack trace is stuck on the loadLibrary call. I *honestly* believe that the VM is irrelevant. As a group, we have seen it on J9, IBM 1.3.0, IBM 1.3.1, and Sun 1.4. We have seen it on Windows platforms, we have seen it on Linux platforms, and we have seen it on Photon. We haven't seen it on Sun 1.3.1, but we only have one data point. I think it has more to do with something else - maybe CPU speed, hard disk speed, amount/speed of RAM - likely something timing-related. Or whatever. But it's *not* specific to any VM. Or platform. I will try to compile a table of who has seen it (or not) and where. IBM 1.3.0 on Windows - Veronika, Carolyn, Shantha, John have seen the problem IBM 1.3.0 on Windows - McQ, Chris, and Shantha did *not* have the problem IBM 1.3.0 on Linux - Veronika, Carolyn, Grant, and Felipe have seen the problem (nobody else in the group has tried IBM 1.3.0 on Linux to my knowledge) IBM 1.3.1 on Windows - Carolyn has seen the problem (nobody else in the group has tried IBM 1.3.1 on Windows to my knowledge) Sun 1.3.1 - Carolyn did *not* have the problem (nobody else in the group has tried Sun 1.3.1 to my knowledge) Sun 1.4 - Adam has seen the problem (nobody else in the group has tried Sun 1.4 to my knowledge) J9 on Windows - Knut has seen the problem J9 on Photon - Silenio has seen the problem Steve swears it's specific to the drop of eclipse. He says he will see it, and then he won't. This is consistent with Shantha's experience. If it is timing- related, then maybe their machines are on the 'cusp' of the problem. :) I will send email to the entire group of people asking for timing-related info on their machines. I don't know if it will help, but maybe we can detect a pattern (i.e. maybe it doesn't happen on "faster, newer" machines or something).
Another potentially important variable here: What VM are you running Eclipse on?
I have seen this. Following is the debugger thread/frames that just showed up in my workspace. NOTES: * it only happens on the first breakpoint ever hit * resuming corrects the problem For the above reasons, I think this problem is related to bug# 15212. I.e. when a thread is initialized, we init its "suspended" state. It is possible that the thread appears as suspended, and we retrieve stack frames for it. The thread later resumes, and the VM does not tell us of this, so we have stale stack frames left in the thread when the breakpoint is hit, and the thread already thinks it is suspended. Thread [main] (Suspended (breakpoint at line 37 in JREContainerInitializer)) ClassLoader.loadLibrary(Class, String, boolean) line: 1410 [local variables unavailable] <not responding> System.loadLibrary(String) line: 832 CoreFileSystemLibrary.<clinit>() line: 51 <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> InternalPlatform.run(ISafeRunnable) line: 802 <not responding> <not responding> <not responding> <not responding> <not responding> DelegatingURLClassLoader.access$0(DelegatingURLClassLoader, String, boolean, DelegatingURLClassLoader, Vector, boolean) line: 740 <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> InternalPlatform.loaderGetRunnable(String) line: 449 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] <not responding> <not responding> <not responding> InternalBootLoader.getRunnable(String) line: 436 InternalBootLoader.run(String, URL, String, String[], Runnable) line: 735 BootLoader.run(String, URL, String, String[]) line: 420 EclipseRuntimeLauncher.main(String[]) line: 16
Note that resuming (or stepping) does not correct the problem if you were stopped at an uncaught exception breakpoint. In this case, resuming ends the program, and you can't debug. (Workaround is to carefully set a breakpoint right before you think the exception will occur, but this doesn't always work either if you are going to hit that code many times before the exception occurs).
I'm still unable to reproduce the problem. I've tried it on 3 machines so far (Windows and Linux). I'm moderately hopeful that Bug 15949 will address this problem. This fix is in today's (20020514) build. Can anyone reproduce this bug on today's build?
I just saw this problem for the first time. I'm using M5, XP and J9 2.0. Note that the problem seems to have happened in Swing in my case, not SWT. I don't know why Swing is running in a runtime Eclipse -- looks like some WSAD thing. Thread [main] (Suspended (breakpoint at line 76 in com.ibm.etools.ctc.scripting.internal.uirenderer.XGRNodePresentation)) sun.awt.Win32GraphicsEnvironment.<clinit>() line: 37 <not responding> <not responding> java.lang.Class.forNameImpl(java.lang.String, boolean, java.lang.ClassLoader) line: not available [native method] java.lang.Class.forName(java.lang.String) line: 115 java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment() line: 64 sun.awt.windows.WToolkit.resetGC() line: 87 sun.awt.windows.WToolkit.<clinit>() line: 77 <not responding> <not responding> java.lang.Class.forNameImpl(java.lang.String, boolean, java.lang.ClassLoader) line: not available [native method] java.lang.Class.forName(java.lang.String) line: 115 <not responding> java.security.AccessController.doPrivileged (java.security.PrivilegedAction) line: 191 java.awt.Toolkit.getDefaultToolkit() line: 500 java.awt.SystemColor.updateSystemColors() line: 348 java.awt.SystemColor.<clinit>() line: 341 <not responding> <not responding> java.lang.Class.forNameImpl(java.lang.String, boolean, java.lang.ClassLoader) line: not available [native method] java.lang.Class.forName(java.lang.String) line: 115 javax.swing.plaf.basic.BasicLookAndFeel.class$(java.lang.String) line: 54 <not responding> <not responding> <not responding> <not responding> javax.swing.UIManager.setLookAndFeel(javax.swing.LookAndFeel) line: 397 com.ibm.db2.tools.common.CommonUIManager.setLookAndFeel (javax.swing.LookAndFeel) line: 132 com.ibm.db2.tools.common.CommonUIManager.setLookAndFeel (java.lang.String) line: 95 com.ibm.db2.tools.common.CommonUIManager.initialize(java.lang.String) line: 218 <not responding> <not responding> com.ibm.etools.subuilder.mgr.SUBuilderIntegrationMgr.getInstance() line: 70 <not responding> <not responding> org.eclipse.core.internal.runtime.InternalPlatform.run (org.eclipse.core.runtime.ISafeRunnable) line: 838 <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> com.ibm.etools.rsc.ui.util.RSCUtil.getActionsFromIConfigurationElements (org.eclipse.core.runtime.IConfigurationElement[], java.lang.String, java.lang.String) line: 276 com.ibm.etools.rsc.ui.util.RSCUtil.getSPActions(java.lang.String, java.lang.String) line: 248 <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> <not responding> org.eclipse.ui.internal.EditorPane (org.eclipse.core.internal.plugins.ConfigurationElement).createExecutableExtens ion(java.lang.String) line: 96 <not responding> org.eclipse.swt.custom.BusyIndicator.showWhile (org.eclipse.swt.widgets.Display, java.lang.Runnable) line: 56 org.eclipse.ui.internal.WorkbenchPlugin.createExtension (org.eclipse.core.runtime.IConfigurationElement, java.lang.String) line: 116 <not responding> <not responding> <not responding> <not responding> org.eclipse.ui.internal.EditorManager (org.eclipse.ui.internal.FolderLayout).addView(java.lang.String) line: 68 <not responding> <not responding> org.eclipse.ui.internal.WorkbenchPage (org.eclipse.ui.internal.Perspective).loadPredefinedPersp (org.eclipse.ui.internal.registry.PerspectiveDescriptor) line: 524 <not responding> <not responding> <not responding> <not responding> org.eclipse.ui.internal.WorkbenchPage.access$11 (org.eclipse.ui.internal.WorkbenchPage, org.eclipse.ui.IPerspectiveDescriptor) line: 505 com.ibm.etools.ctc.ui.workbench.util.WorkbenchUtil$1$OpenEditor (org.eclipse.ui.internal.WorkbenchPage$8).run() line: 2015 org.eclipse.swt.custom.BusyIndicator.showWhile (org.eclipse.swt.widgets.Display, java.lang.Runnable) line: 56 <not responding> org.eclipse.ui.wizards.newresource.BasicNewProjectResourceWizard.replac eCurrentPerspective(org.eclipse.ui.IPerspectiveDescriptor) line: 318 org.eclipse.ui.wizards.newresource.BasicNewProjectResourceWizard.update Perspective(org.eclipse.core.runtime.IConfigurationElement) line: 390 com.ibm.etools.ctc.ui.wizards.newproject.NewProjectWizard.performFinish () line: 87 org.eclipse.jface.wizard.WizardDialog.finishPressed() line: 570 org.eclipse.jface.wizard.WizardDialog.buttonPressed(int) line: 311 org.eclipse.jface.dialogs.Dialog$1.widgetSelected (org.eclipse.swt.events.SelectionEvent) line: 356 org.eclipse.swt.widgets.TypedListener.handleEvent (org.eclipse.swt.widgets.Event) line: 85 org.eclipse.swt.widgets.EventTable.sendEvent (org.eclipse.swt.widgets.Event) line: 75 org.eclipse.swt.widgets.Button (org.eclipse.swt.widgets.Widget).notifyListeners(int, org.eclipse.swt.widgets.Event) line: 637 org.eclipse.swt.widgets.Display.runDeferredEvents() line: 1412 org.eclipse.swt.widgets.Display.readAndDispatch() line: 1208 org.eclipse.jface.wizard.WizardDialog (org.eclipse.jface.window.Window).runEventLoop(org.eclipse.swt.widgets.Shell) line: 538 org.eclipse.jface.wizard.WizardDialog (org.eclipse.jface.window.Window).open() line: 525 org.eclipse.ui.actions.NewProjectAction.run() line: 96 org.eclipse.ui.actions.NewProjectAction (org.eclipse.jface.action.Action).runWithEvent(org.eclipse.swt.widgets.Event) line: 590 org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (org.eclipse.swt.widgets.Event) line: 407 org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent (org.eclipse.swt.widgets.Event) line: 361 org.eclipse.jface.action.ActionContributionItem.access$0 (org.eclipse.jface.action.ActionContributionItem, org.eclipse.swt.widgets.Event) line: 352 org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEv ent(org.eclipse.swt.widgets.Event) line: 47 org.eclipse.swt.widgets.EventTable.sendEvent (org.eclipse.swt.widgets.Event) line: 75 org.eclipse.swt.widgets.MenuItem (org.eclipse.swt.widgets.Widget).notifyListeners(int, org.eclipse.swt.widgets.Event) line: 637 org.eclipse.swt.widgets.Display.runDeferredEvents() line: 1412 org.eclipse.swt.widgets.Display.readAndDispatch() line: 1208 org.eclipse.ui.internal.Workbench.runEventLoop() line: 865 org.eclipse.ui.internal.Workbench.run(java.lang.Object) line: 848 org.eclipse.core.internal.boot.InternalBootLoader.run (java.lang.String, java.net.URL, java.lang.String, java.lang.String[]) line: 777 org.eclipse.core.boot.BootLoader.run(java.lang.String, java.net.URL, java.lang.String, java.lang.String[]) line: 319 EclipseRuntimeLauncher.main(java.lang.String[]) line: 14
I just noticed that I had a bunch of JDI errors in my .log file following this problem. Here's an example: <log-entry date="Tue May 14 15:20:02 EDT 2002"> <status message="Internal Error" severity="ERROR" code="150" plugin-id="org.eclipse.jdt.debug.ui"> <exception trace=" org.eclipse.debug.core.DebugException[5010]: com.sun.jdi.InvalidStackFrameException Stack trace: java/lang/Throwable.<init>()V com/sun/jdi/InvalidStackFrameException.<init>()V org/eclipse/jdi/internal/MirrorImpl.defaultReplyErrorHandler(I)V org/eclipse/jdi/internal/StackFrameImpl.thisObject() Lcom/sun/jdi/ObjectReference; org/eclipse/jdt/internal/debug/core/model/JDIStackFrame.getUnderlyingThisObject ()Lcom/sun/jdi/ObjectReference; org/eclipse/jdt/internal/debug/core/model/JDIStackFrame.getReceivingTypeName ()Ljava/lang/String; org/eclipse/jdt/internal/debug/ui/JDIModelPresentation.getStackFrameText (Lorg/eclipse/debug/core/model/IStackFrame;)Ljava/lang/String; org/eclipse/jdt/internal/debug/ui/JDIModelPresentation.getText (Ljava/lang/Object;)Ljava/lang/String; org/eclipse/debug/internal/ui/LazyModelPresentation.getText (Ljava/lang/Object;)Ljava/lang/String; org/eclipse/debug/internal/ui/DelegatingModelPresentation.getText (Ljava/lang/Object;)Ljava/lang/String; org/eclipse/debug/internal/ui/actions/CopyToClipboardActionDelegate.append (Ljava/lang/Object;Ljava/lang/StringBuffer;Lorg/eclipse/jface/viewers/ILabelPro vider;I)V org/eclipse/debug/internal/ui/actions/CopyToClipboardActionDelegate.append (Ljava/lang/Object;Ljava/lang/StringBuffer;Lorg/eclipse/jface/viewers/ILabelPro vider;I)V org/eclipse/debug/internal/ui/actions/CopyToClipboardActionDelegate.doAction (Ljava/lang/Object;Ljava/lang/StringBuffer;)V org/eclipse/debug/internal/ui/actions/CopyToClipboardActionDelegate$1.run()V org/eclipse/swt/custom/BusyIndicator.showWhile (Lorg/eclipse/swt/widgets/Display;Ljava/lang/Runnable;)V org/eclipse/debug/internal/ui/actions/CopyToClipboardActionDelegate.run (Lorg/eclipse/jface/action/IAction;)V org/eclipse/ui/internal/PluginAction.runWithEvent (Lorg/eclipse/swt/widgets/Event;)V org/eclipse/jface/action/ActionContributionItem.handleWidgetSelection (Lorg/eclipse/swt/widgets/Event;)V org/eclipse/jface/action/ActionContributionItem.handleWidgetEvent (Lorg/eclipse/swt/widgets/Event;)V org/eclipse/jface/action/ActionContributionItem.access$0 (Lorg/eclipse/jface/action/ActionContributionItem;Lorg/eclipse/swt/widgets/Even t;)V org/eclipse/jface/action/ActionContributionItem$ActionListener.handleEvent (Lorg/eclipse/swt/widgets/Event;)V org/eclipse/swt/widgets/EventTable.sendEvent (Lorg/eclipse/swt/widgets/Event;)V org/eclipse/swt/widgets/Widget.notifyListeners (ILorg/eclipse/swt/widgets/Event;)V org/eclipse/swt/widgets/Display.runDeferredEvents()Z org/eclipse/swt/widgets/Display.readAndDispatch()Z org/eclipse/ui/internal/Workbench.runEventLoop()V org/eclipse/ui/internal/Workbench.run(Ljava/lang/Object;)Ljava/lang/Object; org/eclipse/core/internal/boot/InternalBootLoader.run (Ljava/lang/String;Ljava/net/URL;Ljava/lang/String;[Ljava/lang/String;) Ljava/lang/Object; org/eclipse/core/boot/BootLoader.run (Ljava/lang/String;Ljava/net/URL;Ljava/lang/String;[Ljava/lang/String;) Ljava/lang/Object; java/lang/reflect/AccessibleObject.invokeL(Ljava/lang/Object; [Ljava/lang/Object;)Ljava/lang/Object; java/lang/reflect/Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;) Ljava/lang/Object; org/eclipse/core/launcher/Main.basicRun([Ljava/lang/String;) Ljava/lang/Object; org/eclipse/core/launcher/Main.run([Ljava/lang/String;)Ljava/lang/Object; org/eclipse/core/launcher/UIMain.main([Ljava/lang/String;)V " message="com.sun.jdi.InvalidStackFrameException occurred retrieving this from stack frame."> </exception> </status> </log-entry>
Fixed. Tracing revealed that the "suspend on compilation" error support was at fault. We create an invisile breakpoint exception for "java.lang.Error", and when thrown we determine if we are at a location that contains a compilation error. If not, we resume. In my case an UnsatifiedLinkError was being thrown, but there was no compilation error. This causes the thread to silently suspend & resume. The stack frames are cached in the thread, and were not disposed. The next "real" breakpoint that was hit did not re-compute stack frames, and used the old stale frames. Fix was to dispose stack frames when we determine that the thread will not suspend. Please verify.
Verified.
*** Bug 9951 has been marked as a duplicate of this bug. ***
