Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 313874 - [flex][standard model] After a crash, variables not shown in variable view when stopped in a breakpoint
Summary: [flex][standard model] After a crash, variables not shown in variable view wh...
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 3.5.1   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Platform-Debug-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-21 03:54 EDT by Gregory Golberg CLA
Modified: 2019-11-14 03:39 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gregory Golberg CLA 2010-05-21 03:54:41 EDT
Build Identifier: M20090211-1700

This is basically same as https://bugs.adobe.com/jira/browse/FB-26886. However, due to the fact that variables are not shown even for non-Flash-builder applications, the bug is not limited to Flash Builder plug-in, if it's that plugin's fault at all - the platform should be more graceful.

Relevant exception from the log is:


*********************************************************
!ENTRY org.eclipse.core.jobs 4 2 2010-05-12 23:22:23.331
!MESSAGE An internal error occurred during: "child count update".
!STACK 0
java.lang.NullPointerException
at flash.tools.debugger.concrete.PlayerSession.pullUpActivationObjectVariables(PlayerSession.java:1023)
at flash.tools.debugger.concrete.PlayerSession.requestFrame(PlayerSession.java:1000)
at flash.tools.debugger.concrete.DStackContext.populate(DStackContext.java:156)
at flash.tools.debugger.concrete.DStackContext.getThis(DStackContext.java:92)
at flash.tools.debugger.threadsafe.ThreadSafeFrame.getThis(ThreadSafeFrame.java:115)
at com.adobe.flexbuilder.debug.model.FlexStackFrame.initVariables(FlexStackFrame.java:282)
at com.adobe.flexbuilder.debug.model.FlexStackFrame.getVariables(FlexStackFrame.java:409)
at org.eclipse.debug.internal.ui.model.elements.StackFrameContentProvider.getAllChildren(StackFrameContentProvider.java:51)
at org.eclipse.debug.internal.ui.model.elements.StackFrameContentProvider.getChildCount(StackFrameContentProvider.java:28)
at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider.retrieveChildCount(ElementContentProvider.java:114)
at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider$2.run(ElementContentProvider.java:63)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
********************************************************* 

Reproducible: Sometimes

Steps to Reproduce:
See https://bugs.adobe.com/jira/browse/FB-26886
Comment 1 Darin Wright CLA 2010-05-21 12:17:40 EDT
Note that another workaround is to close/re-open the variables view.

I was able to reproduce this problem by making the example PDA debugger throw an NPE in PDAStackFrame#getVariables(). The content/child count job never completes and the view gets left in a corrupt state waiting on the job.
Comment 2 Gregory Golberg CLA 2010-05-21 12:53:52 EDT
> Note that another workaround is to close/re-open the variables view.

Ah, thanks! Much better than restart.
Comment 3 Darin Wright CLA 2010-05-25 11:25:52 EDT
The platform should execute the contributed content/label providers etc., in the style of "safe runnables" in order to avoid leaving the view in a corrupt state. This is too big of a change for 3.6 (at this point in the cycle, and since this is not a regression), but should be considered in a later release.
Comment 4 Lars Vogel CLA 2019-11-14 03:39:15 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

If the bug is still relevant, please remove the "stalebug" whiteboard tag.