If you encounter errors in your applications, you can use the debugging tools to set and manage breakpoints in your code; control application execution by suspending, resuming, and terminating the application; step into and over the code statements; select critical variables to watch; evaluate watch expressions while the application is running, and so on.
Debugging Flex applications can be as simple as enabling trace() statements or as complex as stepping into an application's source files and running the code, one line at a time. The command-line debugger, fdb, let you step through and debug the files used by your Flex applications.
To debug a Flex application, you must generate a debug SWF file. This is a SWF file with debug information in it. You then connect fdb to the debugger version of Adobe® Flash® Player that is running the debug SWF file.
The debugger is an agent that communicates with the application that is running in Flash Player. It connects to your application with a local socket connection. As a result, you might have to disable anti-virus software to use it if your anti-virus software prevents socket communication. The debugger uses this connection to transfer information from the SWF file to the command line so that you can add breakpoints, inspect variables, and do other common debugging tasks. The port through which the debugger connects to your application is 7935. You cannot change this port.
This topic describes how to use the fdb command-line debugger.
To use either debugger, you must install and configure the debugger version of Flash Player. To determine if you are running the debugger version or the standard version of Flash Player, open any Flex application in the player and right-click the mouse button. If you see the Show Redraw Regions option, you are running the debugger version of Flash Player. For more information about the debugger version of Flash Player, and how to detect which player you are running, see Using the debugger version of Flash Player.
The fdb command-line debugger is located in the flex_install_dir/bin directory. To start fdb, open a command prompt, change to that directory, and enter fdb.
For a description of available commands, use the following command:
(fdb) help
For an overview of the fdb debugger, use the following command:
(fdb) tutorial
To debug a Flex application, you first generate a debug SWF file. Debug SWF files are similar to other application SWF files except that they contain debugging-specific information that the debugger and the debugger version of Flash Player use during debugging sessions. Debug SWF files are larger than non-debug SWF files, so generate them only when you are going to debug with them.
To generate the debug SWF file using the mxmlc command-line compiler, you set the debug option to true, either on the command line or in the flex-config.xml file. The following example sets the debug option to true on the command line:
mxmlc -debug=true myApp.mxml
You can use fdb in any gdb-compatible debugging environment. For example, you can use M‑x gdb inside Emacs and specify fdb.exe as the gdb command.
The command-line debugger supports debugging only at the ActionScript level and does not support the Flash timeline concept. The debugger also does not support adding breakpoints inside script snippets in MXML tags. You can set breakpoints on event handlers defined for MXML tags.
Flash Player may interact with a server. The debugger does not assist in debugging the server-side portion of the application, nor does it offer support for inspecting any of the IP transactions that take place from Flash Player to the server, and vice versa.
You can open commands within the fdb debugger by using the fewest number of nonambiguous keystrokes. For example, to use the print command, you can type p, because no other command begins with that letter.
When you debug an application in a web browser, fdb opens the player in the default browser. The default browser is the browser that opens when you open a web-specific file without specifying an application. You must also have the debugger version of Flash Player installed with this browser. If you do not have the debugger version of Flash Player, Flash displays an error indicating that your Flash Player does not support all fdb commands.
Your default browser might not be the first browser that you installed on your computer. For example, if you installed another web browser after installing Microsoft Internet Explorer, Internet Explorer might not be your default browser.
From the Windows toolbar, select Start.
http://www.adobe.com
Click OK.
Windows opens the default browser or displays an error message indicating that there is no application configured to handle your request.
Open the Internet Explorer application.
Select Tools > Internet Options.
Select the Programs tab.
Select the "Internet Explorer should check to see whether it is the default browser" option, and click OK.
The next time you start Internet Explorer, Internet Explorer prompts you to make it the default browser. If you are not prompted, Internet Explorer is already your default browser.
Open the Firefox application.
Select Tools > Options.
Select the General icon to view general settings.
Select the "Firefox should check to see if it is the default browser when starting" option, and click OK.
The next time you start FireFox, FireFox prompts you to make it the default browser. If you are not prompted, FireFox is already your default browser.
Each application can have any number of ActionScript files. Some of the files that fdb steps into are external class files, and some are generated by the Flex compilers.
In general, Flex generates a single file that contains ActionScript statements used in <fx:Script> blocks in the root MXML file, and an additional file for each ActionScript class that the application uses. Flex generates many source files so that you can navigate the application from within the debugger.
To view a list of files that are used by the application you are debugging, use the info files command. For more information, see Getting status.
The generated ActionScript class files are sometimes referred to as compilation units. For more information about compilation units, see About incremental compilation.
By default, you compile applications against the signed framework RSLs. The signed framework RSLs are optimized, which means that they do not include debugging information. If you compile on the command line and use the command line debugger, you must either disable RSLs or specify non-optimized RSLs to use. Otherwise, you will not be able to set break points or take advantage of other debugging functionality.
For more information, see Example of using the framework RSLs on the command line
You start a debugging session by using the fdb command-line debugger. After you start a session, you typically type continue once before you set break points and perform other debugging tasks. This is because the first frame that suspends debugging occurs before the application has finished initialization.
For more information about which commands are available after you start a debugging session, see Using the command-line debugger commands.
You can start a debugging session with the stand-alone debugger version of Flash Player. You do this by compiling the application into a SWF file, and then invoking the SWF file with the fdb command-line debugger. The fdb debugger opens the debugger version of the stand-alone Flash Player.
The debugger version of the stand-alone Flash Player runs as an independent application. It does not run within a web browser or other shell. The debugger version of the stand-alone Flash Player does not support any server requests, such as web services and dynamic SWF loading, so not all applications can be properly debugged inside the debugger version of the stand-alone Flash Player.
Compile the Flex application's debug SWF file and set the debug option to true.
mxmlc -debug=true myApp.mxml
For more information on Flex compilers, see About the Flex compilers.
Find the flex_install_dir/bin directory. You installed the Flex application files to this directory.
Type fdb from the command line. The fdb prompt appears.
java -jar ../lib/fdb.jar
Type run at the fdb prompt, followed by the path to the SWF file, as shown in the following example:
(fdb) run c:/myfiles/fonts/EmbedMyFont.swf
The fdb debugger starts the Flex application in the debugger version of the stand-alone Flash Player, and the (fdb) command prompt appears. You can also start a session by typing fdb filename .swf at the command prompt, rather than by using the run command.
You can start a debugging session in a browser. This requires that you pre-compile the SWF file and are able to request it from a web server.
mxmlc -debug=true myApp.mxml
For more information on Flex compilers, see About the Flex compilers.
Create an HTML wrapper that embeds this SWF file, if you have not already done so. For more information on creating a wrapper, see Creating a wrapper.
Copy the SWF file and its wrapper files to your web server.
Find the flex_install_dir/bin directory. You installed the Flex application files to this directory.
Type fdb in the command line. The fdb prompt appears.
You can also open fdb with the JAR file, as the following example shows:
java -jar ../lib/fdb.jar
Type run at the fdb prompt:
(fdb) run
This instructs fdb to wait for a player to connect to it.
In your browser, request a wrapper that embeds the debug SWF file. Do not request the SWF file directly in a browser because some browsers do not allow you to run a SWF file directly.
Alternatively, you can type run filename .html at the command line, and fdb launches the browser for you. The filename should include the entire URL; for example:
(fdb) run http://localhost:8100/flexapps/index.html
You can configure the current session of the fdb command-line debugger using variables that exist entirely within fdb; they are not part of your application. The configuration variables are prefixed with $.
The following table describes the most common configuration variables used by fdb:
|
Variable |
Description |
|---|---|
$invokegetters |
Set to 0 to prevent fdb from firing getter functions. The default value is 1 (enabled). |
$listsize |
Sets the number of lines to display with the list command. The default value is 10. |
To set the value of a configuration variable, you use the set command, as the following example shows:
(fdb) set $invokegetters = 0
For more information on using the set command, see Changing data values.
The fdb command-line debugger includes commands that you use to debug and navigate your Flex application.
The fdb debugger provides several commands for stepping through the debugged application's files. The following table summarizes those commands:
|
Command |
Description |
|---|---|
continue |
Continues running the application. |
file [file] |
Specifies an application to be debugged, without starting it. This command does not cause the application to start; use the run command without an argument to start debugging the application. |
finish |
Continues until the function exits. |
next [N] |
Continues to the next source line in the application. The optional argument N means do this N times or until the program stops for some other reason. |
quit |
Exits from the debug session. |
run [file] |
Starts a debugging session by running the specified file. To run the application that the file command previously specified, execute the run command without any options. The run command starts the application in a browser or stand-alone Flash Player. |
step [N] |
Steps into the application. The optional argument N means do this N times or until the program stops for some other reason. These commands are nonblocking, which means that when they return, the client has at least begun the operation, but it has not necessarily finished it. |
When you start a session, fdb stops execution before Flex renders the application on the screen. Use the continue command to get to the application's starting screen.
The following example shows a sample application after it starts:
(fdb) continue [trace] ComboBase: y = undefined text_mc.bl = undefined [trace] ComboBase: y = undefined text_mc.bl = undefined [trace] ComboBase: y = undefined text_mc.bl = undefined [trace] ComboBase: y = undefined text_mc.bl = undefined [trace] ComboBase: y = undefined text_mc.bl = undefined [trace] ComboBase: y = undefined text_mc.bl = undefined [trace] ComboBase: y = undefined text_mc.bl = undefined [trace] RadioButtonGroup.addInstance: instance = _level0._VBox0._Accordion0._For m2._FormItem3._RadioButton1 data = undefined label = 2005 [trace] RadioButtonGroup.addInstance: instance = _level0._VBox0._Accordion0._For m2._FormItem3._RadioButton2 data = undefined label = 2004 [trace] RadioButtonGroup.addInstance: instance = _level0._VBox0._Accordion0._For m2._FormItem3._RadioButton3 data = undefined label = 2005 [trace] RadioButtonGroup.addInstance: instance = _level0._VBox0._Accordion0._For m2._FormItem3._RadioButton4 data = undefined label = 2006 [trace] ComboBase: y = 0 text_mc.bl = 12 [trace] ComboBase: y = 0 text_mc.bl = 12 [trace] ComboBase: y = 0 text_mc.bl = 12 [trace] ComboBase: y = 0 text_mc.bl = 14
During the debugging session, you interact with the application in the debugger version of Flash Player. For example, if you select an item from the drop-down list, the debugger continues to output information to the command window:
[trace] SSL : ConfigureScrolling [trace] SSP : 5 51 true 47 [trace] ComboBase: y = 0 text_mc.bl = 14 [trace] layoutChildren : bRowHeightChanged [trace] >>SSL:layoutChildren [trace] deltaRows 5 [trace] rowCount 5 [trace] <<SSL:layoutChildren [trace] >>SSL:draw [trace] bScrollChanged [trace] SSL : ConfigureScrolling [trace] SSP : 5 51 false 46 [trace] SSL Drawing Rows in UpdateControl 5 [trace] <<SSL:draw
You can store commonly used commands in a source file, and then load that file by using the source command. For more information, see Accessing commands from a file.
Setting breakpoints is a critical aspect of debugging any application. You can set breakpoints on any ActionScript code in your Flex application. You can set breakpoints on statements in any external ActionScript file, on ActionScript statements in an <fx:Script> tag, or on MXML tags that have event handler properties. In the following MXML code, click is an event handler property:
<s:Button click="ws.getWeather.send();"/>
Breakpoints are maintained from session to session. However, when you change the target file or quit fdb, breakpoints are lost.
The following table summarizes the commands for manipulating breakpoints with the ActionScript debugger:
|
Command |
Description |
|---|---|
break [args] |
Sets a breakpoint at the specified line or function. The argument can be a line number or function name. With no arguments, the break command sets a breakpoint at the currently stopped line (not the currently listed line). If you specify a line number, fdb breaks at the start of code for that line. If you specify a function name, fdb breaks at the start of code for that function. |
clear [args] |
Clears a breakpoint at the specified line or function. The argument can be a line number or function name. If you specify a line number, fdb clears a breakpoint in that line. If you specify a function name, fdb clears a breakpoint at the beginning of that function. With no argument, fdb clears a breakpoint in the line that the selected frame is executing in. Compare the delete command, which clears breakpoints by number. |
commands [breakpoint] |
Sets commands to execute when the specified breakpoint is encountered. If you do not specify a breakpoint, the commands are applied to the last breakpoint. |
condition bp_num [expression] |
Specifies a condition that must be met to stop at the given breakpoint (identified by the breakpoint number). The fdb debugger evaluates expression when the breakpoint is reached. If the value is true or nonzero, fdb stops at the breakpoint. Otherwise, fdb ignores the breakpoint and continues execution. To remove the condition from the breakpoint, do not specify an expression. You can use conditional breakpoints to stop on all events of a particular type. For example, to stop on every initialize event, use the following commands: (fdb) break UIEvent:dispatch Breakpoint 18 at 0x16cb3: file UIEventDispatcher.as, line 190(fdb) condition 18 (eventObj.type == 'initialize') |
delete [args] |
Deletes breakpoints. Specify one or more comma- or space-separated breakpoint numbers to delete those breakpoints. To delete all breakpoints, do not provide an argument. |
disable breakpoints [bp_num] |
Disables breakpoints. Specify one or more space-separated numbers as options to disable only those breakpoints. |
enable breakpoints [bp_num] |
Enables breakpoints that were previously disabled. Specify one or more space-separated numbers as options to enable only those breakpoints. |
The following example sets a breakpoint on the myFunc() method, which is triggered when the user clicks a button:
(fdb) break myFunc Breakpoint 1 at 0x401ef: file file1.mxml, line 5 (fdb) continue Breakpoint 1, myFunc() at file1.mxml:5 5ta1.text = "Clicked"; (fdb)
To see all breakpoints and their numbers, use the info breakpoints command. This will also tell you if a breakpoint is unresolved.
You can use the commands command to periodically print out values of objects and variables whenever fdb encounters a particular breakpoint. The following example prints out the value of ta1.text (referred to as $1), executes the where command, and then continues when it encounters the button's click handler breakpoint:
(fdb) commands 1 Type commands for when breakpoint 1 is hit, one per line. End with a line saying just 'end'. >print ta1.text >where >continue >end (fdb) cont Breakpoint 1, myFunc() at file1.mxml:5 5ta1.text = "Clicked"; $1 = "" #0 [MovieClip 1].myFunc(event=undefined) at file1.mxml:5 #1 [MovieClip 1].handler(event=[Object 18127]) at file1.mxml:15
Breakpoints are not specific to a single SWF file. If you set a breakpoint in a file that is common to multiple SWF files, fdb applies the breakpoint to all SWF files.
For example, suppose you have four SWF files loaded and each of those SWF files contains the same version of an ActionScript file, view.as. To set a breakpoint in the init() function of the view.as file, you need to set only a single breakpoint in one of the view.as files. When fdb encounters any of the init() functions, it triggers the break.
(fdb) watch variable_name
You can use the source command to read fdb commands from a file and execute them. This lets you write commands such as breakpoints once and use them repeatedly when debugging the same application in different sessions or across different applications.
The source command has the following syntax:
(fdb) source file
The value of file can be a filename for a file in the current working directory or an absolute path to a remote file. To determine the current working directory, use the pwd command.
The following examples read in the mycommands.txt file from different locations:
(fdb) source mycommands.txt (fdb) source mydir\mycommands.txt (fdb) source c:\mydir\mycommands.txt
The print command displays values of members such as variables, objects, and properties. This command excludes functions, static variables, constants, and inaccessible member variables (such as the members of an Array).
The print command uses the following syntax:
print [variable_name | object_name[.] | property]
The print command prints the value of the specified variable, object, or property. You can specify the name or name.property to narrow the results. If fdb can determine the type of the entity, fdb displays the type.
If you specify the print command on an object, fdb displays a numeric identifier for the object.
To list all the properties of an object, use trailing dot-notation syntax. The following example prints all the properties of the object myButton:
(fdb) print myButton.
To print the value of a single variable, use dot-notation syntax, as the following example shows:
(fdb) print myButton.label
Use the what command to view the context of a variable. The what command has the following syntax:
(fdb) what variable
Use the display command to add an expression to the autodisplay list. Every time debugging stops, fdb prints the list of expressions in the autodisplay list. The display command has the following syntax:
(fdb) display [expression]
The expression is the same as the arguments for the print command, as the following example shows:
(fdb) display myButton.color
To view all expressions on the autodisplay list, use the info display command.
To remove an expression from the autodisplay list, use the undisplay command. The undisplay command has the following syntax:
(fdb) undisplay [list_num]
Use the undisplay command without an argument to remove all entries on the autodisplay list. Specify one or more list_num options separated by spaces to remove numbered entries from the autodisplay list.
You can temporarily disable autodisplay expressions by using the disable display command. The disable display command has the following syntax:
(fdb) disable display [display_num]
Specify one or more space-separated numbers as options to disable only those entries in the autodisplay list.
To re-enable the display list, use the enable display command, which has the same syntax as the disable display command.
You can use the set command to assign the value of a variable or a configuration variable. The set command has the following syntax:
set [expression]
Depending on the variable type, you use different syntax for the expression. The following example sets the variable i to the number 3:
(fdb) set i = 3
The following example sets the variable employee.name to the string Reiner:
(fdb) set employee.name = "Reiner"
The following example sets the convenience variable $myVar to the number 20:
(fdb) set $myVar = 20
You use the set command to set the values of fdb configuration variables. For more information, see Configuring the command-line debugger.
You use the list command to view lines of code in the ActionScript files. The list command uses the following syntax:
list [- | line_num[,line_num] | [file_name:]line_num | file_name[:line_num] | [file_name:]function_name]
You use the list command to print the lines around the specified function or line of the current file. If you do not specify an argument, list prints 10 lines after or around the previous listing. If you specify a filename, but not a line number, list assumes line 1.
If you specify a single numeric argument, the list command lists 10 lines around that line. If you specify more than one comma-separated numeric argument, the list command displays lines between and including those line numbers.
To set the list location to where the execution is currently stopped, use the home command.
The following example lists code from line 10 to line 15:
(fdb) list 10, 15
If you specify a hyphen (-) in the previous example, the list command displays the 10 lines before a previous 10-line listing.
Specify a line number to list the lines around that line in the current file, as in the following example:
(fdb) list 10
Specify a filename followed by a line number to list the lines around that line in that file, as in the following example:
(fdb) list effects.mxml:10
Specify a function name to list the lines around the beginning of that function, as in the following example:
(fdb) list myFunction
Specify a filename followed by a function name to list the lines around the beginning of that function. This lets you distinguish among like-named static functions, as follows:
(fdb) list effects.mxml:myFunction
You can resolve ambiguous matches by extending the value of the function name or filename, as the following examples show:
Filenames:
(fdb) list UIOb Ambiguous matching file names: UIComponent.as#66 UIComponentDescriptor.as#67 UIComponentExtensions.as#68 (fdb) list UIComponent.
Function names:
(fdb) list init Ambiguous matching function names: init initFromClipParameters (fdb) list init(
The list command acts on the current file by default. To change to a different file, use the cf command. The cf command has the following syntax:
(fdb) cf [file_name|file_number]
For example, to change the file to MyApp.mxml, use the following command:
(fdb) cf MyApp.mxml
If you do not specify a filename, the cf command lists the name and file number of the current file.
To view a list of all files used by the current application, use the info files command. For more information, see Getting status.
Use the pwd command to view the file system's current working directory, as the following example shows. This is the directory from which fdb was run.
(fdb) pwd c:/Flex2SDK/bin/
Usually, fdb can find the source files for your application to display them with the list command. In some situations, however, you need to add a directory to the search path so that fdb can find the source files. This can be necessary, for example, when the application was compiled on a different computer than you are using to debug the application.
You use the directory command to add a directory to the search path. This command adds the specified directory or directories to the beginning of the list of directories that fdb searches for source files. The syntax for the directory command is as follows:
(fdb) directory path
For example:
(fdb) directory C:\MySource;C:\MyOtherSource
On Windows, use the semicolon character as a separator. On Macintosh and UNIX, use the colon character as a separator.
To see the current list of directories in the search path, use the show directories command.
The fdb debugger supports truncated file and function names. You can specify file_name and function_name arguments with partial names, as long as the names are unambiguous.
If you use truncated file and function names, fdb tries to map the argument to an unambiguous function name first, and then a filename. For example, list foo first tries to find a function unambiguously starting with foo in the current file. If this fails, it tries to find a file unambiguously starting with foo.
Use the bt command to display a back trace of all stack frames. The bt command has the following syntax:
(fdb) bt
Use the info command to get general information about the application. The info command has the following syntax:
info [options] [args]
The info command displays general information about the application being debugged. The following table describes the options of the info command:
|
Option |
Description |
|---|---|
|
arguments |
Displays the argument variables of the current stack frame. |
|
breakpoints |
Displays the status of user-settable breakpoints. |
|
display |
Displays the list of autodisplay expressions. |
|
files [arg] |
Displays the names of all files used by the target application. This includes authored files and system files, plus generated files. Also indicates the file number for each file. You can use wildcards and literals to select and sort the output. The info files command supports the following: info files character Alphabetically lists files with names that start with the specified character. The following example lists all files starting with the letter V: info files V info files *.extension Alphabetically lists all files with the given extension. The following example lists all files with the as extension: info files *.as info files *string* Alphabetically lists all files with names that include string. |
|
functions [arg] |
Displays all function names used in this application. The info functions command optionally takes an argument; for example: info functions Lists all functions in all files. info functions Lists all functions in the current file. info functions MyApp.mxml Lists all functions in the MyApp.mxml file. |
handle |
Displays settings for fault handling in the debugger. |
|
locals |
Displays the local variables of the current stack frame. |
|
sources |
Displays authored source files used by the target application. |
stack |
Displays the backtrace of the stack. |
swfs |
Displays all current SWF files. |
targets |
Displays the HTTP or file URL of the target application. |
|
variables |
Displays all global and static variable names. |
For additional information about these options, use the help command, as the following example shows:
(fdb) help info targets
Use the handle command to specify how fdb reacts to Flash Player exceptions during execution. To view the current settings, use the info command, as the following example shows:
(fdb) info handle
The handle command has the following syntax:
(fdb) handle exception [action]
The fault_type is the category of fault that fdb handles. The action is what fdb does in response to that fault. The possible actions are print, noprint, stop, and nostop. The following table describes these actions:
|
Action |
Description |
|---|---|
|
|
Prints a message if this type of fault occurs. |
noprint |
Does not print a message if this type of fault occurs. |
stop |
Stops execution of the debugger if this type of fault occurs. |
nostop |
Does not stop execution of the debugger if this type of fault occurs. |
(fdb) catch exception_type
(fdb) catch TypeError
(fdb) catch *
Use the help command to get information on particular topics. The help command has the following syntax:
help [topic]
The help command provides a relatively terse description of each command and its usage. The following example opens the help command:
(fdb) help
Type help followed by the command name to get the full help information, as the following example shows:
(fdb) help delete
You use the kill and exit commands to end the current debugging session and exit from the fdb application. The kill and exit commands do not take any arguments. If fdb opened the default browser, you can also terminate the fdb session by closing the browser window.
To stop the current session, use the kill command, as the following example shows:
(fdb) kill
Using the kill command does not quit the fdb application. You can immediately start another session. To exit from fdb, use the exit command, as follows:
(fdb) exit
Navigation
Adobe, Adobe Flash and Adobe Flash Player are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries and are used by permission from Adobe. No other license to the Adobe trademarks are granted.