|Prerequisite knowledge||Required products
To make the most of this article, you should have a basic knowledge of Flex development. You should also have a basic understanding of how to use the Flash Builder 4 IDE and how to import FXP Flex project archives.
Debug perspective: new features
- Support for expression types in the Expressions view has been enhanced.
- Watchpoints are available to help you debug variable instances.
- Conditional breakpoints support has been added.
- The run to line feature will help you strike a happy medium between coding manual trace statements in your code and having so many breakpoints in your code that debugging becomes ineffective.
- Extract the FXP Flex Project Archive from the sample file and import it into Flash Builder 4.
- Open Devnet_FB4_New_Debugging_Profiling_Features.mxml located in src/(default package).
- Set a breakpoint inside the
for eachloop by clicking on line 34 and choosing Run > Toggle Breakpoint.
- Launch the sample application in debug mode by choosing Run > Debug > Devnet_FB4_New_Debugging_Profiling_Features
- Wait for the breakpoint to halt the application.
- When the application has halted make sure you are in the Flash Builder Debug perspective by choosing Window > Perspective > Flash Debug
- Locate the Expressions view in the Flash Debug perspective.
- Right-click in the Expressions view and select Add Watch Expression.
- In the Add Watch Expression dialog box type item..* to view all XML descendents of item and click OK to add the watch expression.
- When you see the E4X expression evaluated, expand the XMLList to view each of the descendents (see Figure 1).
Figure 1: The Flash Builder 4 enhanced expression evaluator with support for E4X
sourceproperty of an
<mx:Image/>tag to monitor changes to that property.
- Keep the breakpoint that was set in walkthrough 1 and run the application again in debug mode.
- Wait for the application to pause execution.
- While the application is suspended, find the Variables view in the Debug perspective.
- Expand the
thisinstance in the variables view.
rotatingImagein the Variables view.
- Right-click the
- Select Toggle Watchpoint in the context menu.
- A Toggle Watchpoint dialog box will appear because
sourceis a getter. Select the
_sourcevariable instance to monitor and click OK.
- Locate the Breakpoints view in the Debug perspective and find the new watchpoint.
- While still in the Breakpoints view, clear the Line 34 breakpoint that had been set in Walkthrough 1.
- Resume the execution of your application by choosing Run > Resume
- After a short wait you will see the watchpoint suspend the application once more. You should also notice that the source code for SWFLoader is where the
_sourceinstance is being changed (see Figure 2).
- Resume the application again and you will notice that the watchpoint is hit each time the
_sourceinstance for the
<mx:Image/>tag is changed.
Figure 2. Suspending on a watchpoint in Flash Builder 4.
forloop. You may need to suspend the application only once during the debug session to verify your logic, but you’ll hit the breakpoint in the
forloop each time through. You’ll then have to take the additional step of removing the breakpoint to continue the debug session without stopping on each iteration of the loop.
true. In the next walkthrough you will make the breakpoint that was set up in the first walkthrough conditional by adding an expression.
- Run the application normally by choosing Run > Run > Devnet_FB4_New_Debugging_Profiling_Features
- Wait for the data to load and select a specific author name, for example "Adobe".
- Close the application and enter the Flash Debug perspective.
- Set a breakpoint inside the for each loop by clicking on line 34 and choosing Run > Toggle Breakpoint.
- In the Flash Debug perspective, locate the Breakpoints view and right-click the breakpoint that you just created.
- In the context menu select Breakpoint Properties
- Take a quick look at the options available to you, and then select Enabled if not pre-selected for you.
- Select Enable Condition.
- In the Enable Condition text input, type a condition that will evaluate to true when the author's name that you identified in step 2 is present. For example, type item.author == "Adobe" (see Figure 3).
Figure 3. Creating a conditional breakpoint
- Click OK to exit Breakpoint Properties dialog box.
- Run the application in debug mode and wait for the application to suspend.
- When the application suspends, open the Variables view and click the
itemvariable. If you look at the value of
itemyou will see that the author node in the XML is equal to the author name that you had specified in the breakpoint condition in step 9 (see Figure 4).
Figure 4. The conditional breakpoint for item.author=="Adobe"
- Resume the application. If the author you chose had multiple articles, then the conditional breakpoint will be triggered each time that author is reached, but only when that author is reached.
tracestatement after the
for eachloop quickly.
- Keeping the conditional breakpoint from the last walkthrough, run the application in debug mode.
- Wait for the conditional breakpoint to trigger and once the execution of the application has paused, look at
devnetFeed_resultHandler()in the code editor.
- To finish debugging the
for eachloop, disable the conditional breakpoint that was set on line 34 by deselecting it in the Breakpoints view.
- Put the cursor on line 39 of the code, which reads
var aNumber:int = 1974.
- Right-click and select Run To Line.
- You will see that the results are immediate. Figure 5 shows that code execution will halt on the line you chose to run to during the debug session without having to step debug or set another breakpoint.
Figure 5. Using the run to line feature
Profile perspective: new features
- First, launch the sample application in Profile mode by choosing Run > Profile > Devnet_FB4_New_Debugging_Profiling_Features.
- When the profiling session launches you will see a Connection Established dialog box.
- Since you're trying to track down a memory leak, select Generate Object Allocation Stack Traces and click Resume. Flash Builder 4 will open the Flash Profile perspective.
- Let the application run for several seconds so that it can generate profile data, and then look at the Live Objects view.If you see any objects in the Live Objects view that have more instances than you know there should be, those objects may indicate a memory leak–especially if the number of instances is equal to the number of cumulative instances.In the case of the sample application, it is highly suspect that there are so many instances of the BadTitleWindow class still in memory.
- Select the “[Running]…” application in the Profile view and click the Take Memory Snapshot button in the Profile view toolbar.
- Double-click the memory snapshot in the Profile view to open it, and then wait for Flash Builder to analyze the memory snapshot.
- Once the memory snapshot is available, double-click the BadTitleWindow class to open the Object References view (see Figure 6).
Figure 6. Flash Builder 4 Object References View
- Expand the first BadTitleWindow instance; you will see several paths.
- Expand Path 1 (see Figure 7). Notice in the GC Root column that this back reference path does terminate at a GC Root (you may need to adjust the column widths).Note: There is a chance that the order in which your Paths are listed is different. If this is the case, find the instance with a Path that resembles Figure 7 before moving on to Step 10. Also, Flash Builder is configured not to show all paths by default. To enable Flash Builder to show all paths: Flash Builder --> Preferences... --> Flash Builder --> Profiler --> Object References --> check the "Show all back-reference paths" checkbox and apply your changes.
Figure 7. Object References view with Path 1 expanded
- Click the BadTitleWindow instance in the path and look at the Allocation Trace in the right pane. You will see that this instance was created in the
_onPopupTimer()method of the main application MXML file.
- Now click the Function instance in the left pane.
- In the Allocation Trace panel you can see that the Function instance was created in the BadTitleWindow constructor on line 16 (see Figure 8).
Figure 8. The Object References view allocation Trace
- Double-click the row in the Allocation Trace that represents line 16 of the BadTitleWindow constructor. If the source code is available, double-clicking on a row in the Allocation Trace pane will take you to the line of code where the instantiation was initiated (see Figure 9).
Figure 9. Memory leak identified from the Object References view
- Notice that line 16 creates a reference from the main application to the BadTitleWindow. Since this is not a weak reference, it will keep the BadTitleWindow object in memory even if this is the only reference to BadTitleWindow. In other words, this line of code is what caused this memory leak.
- Comment out line 16, save your changes, and then build and run the application in profile mode once more. Let it run and watch the number of instances and the number of cumulative instances. You will see that the BadTitleWindow instances are no longer being leaked.
Figure 10. The Flash Builder 4 Network Monitor
Where to go from here