JVM Memory Leak With Attached Language Debuggers

Sun identified a fault with their JVM product (on which most CFML engines run) which can cause memory to leak when a language debugger is attached and access the target machine in a certain (well-documented and Sun-approved) way.

Sun are tracking this issue under bug ID 4858370 here:

http://bugs.sun.com/view_bug.do?bug_id=4858370

Symptoms

During a long debugging session, you may find that the target JVM memory usage increases by a small amount, which is never reclaimed by Java. Under tests, FusionDebug was shown to have a minimal drain on memory due to this issue.

Fix

Since this is a known issue with the JVM, a Sun Microsystems product, it will be solved in a future JVM release. Customers should generally not experience this issue except when performing extremely long debugging sessions. Memory is reclaimed normally if the JVM is restarted.

Using An Interactive Debugger To Increase Productivity

This recorded webinar reviews how to install FusionDebug and configure it for use with a Railo server in addition to discussing the many features FusionDebug offers.

Webinar Outline

• Installing FusionDebug
  
  
  
  
  • Connecting FusionDebug with Railo
    
    
    
    
• FusionDebug Feature Run-Down
  
  
  
  
  • Supported Platforms
    • ColdFusion 6, 7, 8 (Std/Ent/Dev), 9
    • Railo 3.1.x
    • Eclipse: 3.1, 3.2, 3.3, 3.4, 3.5, 3.6
  • Conditional Breakpoints
  • Break on Runtime Exceptions
  • Run to Line
  • Advanced Stepping Technology
  • Source Code Lookups
  • View Variables and Scopes (including queries)
  • Expression Watcher
  • Multiple Request Support
  • Full Stack Traces (including function arguments)
    
    
    
    
• Summary

Watch Webinar

FusionDebug Introduction (with Railo) – Part 1 of 6
FusionDebug Introduction (with Railo) – Part 2 of 6
FusionDebug Introduction (with Railo) – Part 3 of 6
FusionDebug Introduction (with Railo) – Part 4 of 6
FusionDebug Introduction (with Railo) – Part 5 of 6
FusionDebug Introduction (with Railo) – Part 6 of 6

Get Started Debugging

Download a free trial of FusionDebug

About FusionDebug

FusionDebug is the fastest interactive step debugger for CFML and supports multiple engines (ColdFusion and Railo).

Introduction

I ran into a situation while working on a MachII application running on Railo 3.1 where I REALLY need to see what was going on with the various variable scopes during the request cycle, so I decided tonight to see if I could get FusionDebug 3 Beta up and running with Railo and Tomcat.

For the past couple of months, I’ve been running my CFML server engines (yes engines, plural) on top of Tomcat on my local development environment. This offers me, as an independent developer that works on a number of different client projects, a great deal of flexibility in matching a particular client’s production configuration. Also lately, I’ve been working on a couple of projects using Railo 3.1 as well as a project for a client that still uses CFMX 7. One of the things that I really missed when not developing with ColdFusion 8 is the step debugger that ships with CF8. I’d used FusionDebug some time ago with CFMX 7 when I was running it on top of JRun 4 but had never gotten around to getting it configured under my current, Tomcat-based setup.

Environment

Before we get started, I want to detail my particular setup and lay out some assumptions. My environment consists of the following components. Yours might be slightly different, but the basics should be the same.

• Apache 2.2.11 web server configured with one virtual host per client site
• Tomcat 6 installed into /opt/tomcat
• Apache forwards ColdFusion requests to Tomcat via AJP
• http://localhost web root is /Users/dskaggs/Sites/localhost/htdocs
• WEB-INF folder from exploded Railo 3.1 WAR file resides in the web root folder

Now for some assumptions:

• You can browse to a CFML page (either by going directly to Tomcat http://localhost:8080/someContext/test.cfm or through Apache http://localhost/test.cfm )
• You’ve installed FusionDebug into Eclipse using the instructions in the “Install FusionDebug into Eclipse” section here
• You’ve created a project in Eclipse that points to your site files
• You don’t have Tomcat starting as a daemon or Windows service
  
  
  
  

Setting up Tomcat

The first thing that you have to do is tell Tomcat to enable debugging on a specific TCP port. For this example the port number that we’re going to use is 8000 (the same as the documentation on the FusionDebug site). You do this by adding the following line of code to the catalina.sh file in the /bin folder under the Tomcat install directory (in my case /opt/tomcat/bin/catalina.sh). I added it directly under the large comment block at the top of the file.

CATALINA_OPTS=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000

If you’re on Windows, this file is named catalina.bat and the format is slightly different:

set CATALINA_OPTS=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000

Save the file and launch Tomcat. In my case, I launched it in a terminal window so I could see exactly what was going on using the command:

cd /opt/tomcat/bin
sudo ./catalina.sh run

If everything worked correctly, you’ll see the following line near the top of the output to the console:

Listening for transport dt_socket at address: 8000

That concludes the configuration necessary on the Tomcat side.

Configuring FusionDebug

Now we need to get FusionDebug configured to connect to that port. In Eclipse, go to Window > Open Perspective > Other and choose FusionDebug from the list that appears in the popup window.

Then you’ll need to open up the Debug Configurations panel by going to Run > Debug Configurations. Find the entry for Fusion Debug in the left side, right click on it and choose “New” from the context menu. Enter a descriptive string in the Name: block at the top of the left side of the screen (I used simply Localhost). Then move to the configuration panel below with the 3 tabs (Connect, Source Code Lookup, and Common).

On the connect tab, enter localhost in the Host: block and 8000 in the Port: block.

On the Source Code Lookup tab, in the drop list that says “<All Projects>”, choose the Eclipse project that contains your files. In the drop list just to the right of the Project select box you just clicked on, choose the folder that corresponds to the web root of your site. Finally, enter the full file system path that corresponds to the folder you just chose and click the Add button. Click the Apply button to save the configuration. You can then click the Debug button at the bottom of the screen to start the debug session. If all goes well, you’ll see “FusionDebug (localhost:8000) (Connected)” in the Debug pane.

Testing

Now it’s just a matter of creating a test.cfm file (or using an existing file), setting some breakpoints and browsing to the file and you should see the execution stop at your breakpoint and be able to browse through the list.

In order to run FusionDebug 3 (or higher) against Railo on the Caucho Resin platform, Resin must be configured to allow debugging connections.

This is configured in RESIN_HOME\conf\resin.conf

• Ensure Resin is halted.
• Locate the file mentioned above and edit it.
• Locate the block of jvm-arg configuration items and add

<jvm-arg>-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000</jvm-arg>

to the list.

• Restart Resin.

If debugging has been configured, you will see:

Listening for transport dt_socket at address: 8000

as the first line of the Resin startup.

FusionDebug Rev. 3.0

^{FDNG-EDTRUNK.161.14367}

RELEASE NOTES – KNOWN ISSUES – ADDITIONAL LICENSE AGREEMENTS

INTERGRAL INFORMATION SOLUTIONS GMBH
Schickardstr 32 – D-71034 Boeblingen – Germany

The FusionDebug software is Copyright (C) 2006-2009 Intergral Information Solutions GmbH.
All rights reserved. The FusionDebug software product is commercial software and may not be
redistributed except with the express written agreement of Intergral Information Solutions GmbH.
The software may only be used in accordance with the appropriate FusionDebug license agreement.

Status: Mon, 03 Aug 2009

RELEASE NOTES

• FusionDebug Rev. 3.0.0

• FusionDebug Rev. 3.0.0 introduces a modular interface structure allowing different debug engines
  to be used as debug targets. This has been built with support for Railo 3.2 and CF 6.1, 7, 8 when run in
  debug mode (see guides for instructions on starting Railo/CF in debug mode). Support for
  debugging other languages may be added by releasing FD debug connector modules.

• No license is required during 20 day trial. After the period expires, you will be unable to launch any
  debug sessions until a valid license is installed, or a licensed server is connected too.

• New server license. Railo Enterprise edition users will be able to debug without a client license.

• Eclipse 3.4 (Ganymede) and 3.5 (Galileo) now supported.

• Conditions can be added to breakpoint properties, in the form of CFML expressions.
  This gives you more control over when your breakpoints fire, letting only valid conditions evaluating to TRUE to hit.

• Break on runtime exceptions, Railo and CF connectors are able to stop on different exception types.
  Railo connector currentlyy supports; application, expression, database, custom_type, lock,
  missinginclude, native, security and template exceptions.
  CF connector currently supports: custom exceptions.
  See user guide for more information on exception breakpoints.

• Run to line function added. Perform a run to line operation using the context menu in an editor
  or the shortcut CTRL+R on your currently selected line.
  The Eclipse Run/Debug setting to skip breakpoints during a run to line operation is honored.

• Set Variable dialog now gives you more control and freedom allowing modification of the variable and it’s value.
  The highlighted variable can be blank for complete user input.

• Custom file extension support added. Run and debug custom file extension CFML files.
  For more information on configuring servers for this see the user guide.

• FusionDebug Rev. 3.0 has been tested using Eclipse Platform 3.2 to 3.5 (Galileo) on
  Microsoft Windows XP SP2, Microsoft Windows Vista SP 1. FusionDebug is a pure Java
  application with no native dependencies, and so should run on all OS platforms for which Eclipse is
  available.

• We recommend installing the Eclipse Java SDK package. This can be obtained from http://www.eclipse.org/downloads/

• We recommend also installing the CFEclipse package, which provides a capable environment for
  working with CF scripts within Eclipse. This can be obtained from: http://www.cfeclipse.org/

• Please consult the relevant Guides for quick-start instructions on getting acquainted with FusionDebug. There is
  an updated User Manual for 3.0.

KNOWN ISSUES

FusionDebug Rev. 3.0

The following issues are known at the time of publication.

General

• ‘Run To Line’ Causes Skip On Following CFML Code/Breakpoints With Resume/Steps

As Run To Line targets are set anywhere on a CFML page, and we expect the execution to halt at this point, the engine must be allowed to continue to the ‘next nearest’ valid CFML, and halt there. This can therefore be on another Breakpoint, causing it to seem (upon step/resume) to be skipped, where as it has simply already been hit.

• Custom Extensions Not Recognized By CFML Server

For your Custom Extensions to function you must add them to your CFML Servers known extensions. For advice on how to do this please see our user manual or web page. These contain useful links and setup instructions, as well as guides on setting your default editors. You will need to set your IDE to use editors that allow debugging on your new extensions (including the default .htm .html).

For information and instructions on use please see:
http://www.fusion-reactor.com/fd/support.cfm

CF Specific

• Custom Exceptions Fire In CF Admin/Other CF Web Applications Pages When FusionDebug Connected

This is a side effect of breaking on Exceptions, any CFML Live code running on the attached server can fire off Custom Exceptions, which FusionDebug will detect (when option selected). To use these applications during a debug session simply uncheck the option to ‘Catch Un/Caught Custom CFML Exceptions’ in the FusionDebug ‘Configuration’ Page in ‘Preferences’, from the ‘Window’ menu option. You can then re-enable the setting once you have finished using the desired page and continue debugging.

• Custom Exceptions Within CFTRY Recognized As Caught When NOT Handled In CFCATCH

When placed within a cftry/cfcatch block thrown Custom Exceptions are dealt with as Caught by CFML. Therefore even though this is Uncaught by rights, it will only be detected as caught (with this option). When this occurs the catch block will be highlighted also – due to the match not being correct. The distinction between whether ‘this’ Custom Exception, is Caught based upon the catch type is something we are working on and plan to have resolved for next Beta/Release.

Railo Specific

• FD-493/RAILO-195 Stepping is innacurate within very long pages. You may find the line cursor skips to an incorrect line, or skips back and forth, when debugging very large CFC or CFM pages.

GENERAL ISSUES

Some Numerical / Complex CF Types Decode to Java Types, Not CF Types

We’re working hard on being able to decode all CFML complex types. Most types are already
implemented – structs, arrays, XML objects, CFCs, Functions etc. In some cases, you might see
an undecoded type in the Variables and Expressions view (“… instance of …”) or a plain
string representation of the object.

Step Over sometimes requires > 1 keypress to advance the cursor.

This is because some lines of CF code perform multiple actions and require you to press
step for each action that they perform.

Step Into CFC’s is sometimes requires > 1 keypress to step into the CFC.

With the current instruction pointer located on the CFINVOKE tag, keep clicking Step Into until
the CFC is loaded. The parameters and other initialization actions are performed before the CFC
is called. You may have to push step into until this initialization is complete.

Step Requests sometimes jump around to lines of code that are not sensible.

This is a limitation of how Railo processes and optimizes pages at compile time.

Calling CFML functions which are reentrant to the currently halted thread may cause the VM to hang

You cannot set/clear breakpoints with CTRL-SHIFT-B when in the CFEclipse perspective

CFEclipse does not support the CTRL-SHIFT-B keystroke when in the CFEclipse perspective. You
can toggle the breakpoint by right mouse clicking on the line you wish to set the breakpoint
on and using the Toggle Line Breakpoint menu item.

Sometimes breakpoints don’t fire.

In the Debug configuration, make sure the Target System Type is set correctly: checked for
Windows, unchecked for Unix. And the correct connector is being used for the engine type desired.

Breakpoints set on blank lines may not always fire.

Since FD 2.0.1 breakpoints can be set on blank lines. FD cannot always get breakpoints to
fire on blank lines because they are sometimes optimized away by the CF compiler.

Wrong File Selected

When a breakpoint or step event fires, FusionDebug does its best to find the source file. If the
same file exists multiple times in different projects, the wrong one may be selected
Use the source code lookup tab on the Launch Control to correct the source code lookups.

If your system is monitored by FusionReactor with crash protection activated, FusionReactor may

terminate the page if it exceeds the Request Timeout limit that has been configured. Please
deactivate crash protection in FusionReactor.

RESOLVED ISSUES

ADDITIONAL LICENSE AGREEMENTS

This Software contains code derived from the Eclipse Foundation (“Eclipse Code”).
Such Eclipse Source Code is made available under the terms of the Eclipse Public License v1.0 which
accompanies such code, and is also available at http://www.eclipse.org/legal/epl-v10.html

Eclipse Code. On behalf of Contributors to such Eclipse Code, Intergral hereby: (1) disclaims any and all
warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability
and fitness for a particular purpose with respect to such Eclipse Code and any and all derivative works thereof,
(2) disclaims any liability for damages, including direct, indirect, special, incidental and consequential
damages, such as lost profits, and (3) represents that any provisions in this License Agreement that differ
from the Eclipse Public License under which Intergral licensed the Eclipse Code, are offered by Intergral
alone and not by any other party. The source code for the Eclipse Code as contained in this Software may be
obtained by the Licensee as described in in this Readme to the Software. Intergral provides the Eclipse Code as
is, without warranty or support from Intergral.

By installing this product, in addition to the Intergral license terms, you also agree to be bound by the
third-party terms provided to you with the Intergral product documentation. Intergral recommends that you review
these third-party terms.

FusionDebug Rev. 3.0.1

RELEASE NOTES – KNOWN ISSUES – ADDITIONAL LICENSE AGREEMENTS

INTERGRAL INFORMATION SOLUTIONS GMBH
Schickardstr 32 – D-71034 Boeblingen – Germany

The FusionDebug software is Copyright (C) 2006-2009 Intergral Information Solutions GmbH.
All rights reserved. The FusionDebug software product is commercial software and may not be
redistributed except with the express written agreement of Intergral Information Solutions GmbH.
The software may only be used in accordance with the appropriate FusionDebug license agreement.

Status: Fri, 27 Nov 2009

RELEASE NOTES

• FusionDebug Rev. 3.0.1

• ColdFusion 9 support. You can now also debug ColdFusion 9 Servers.

• Further integration with the ColdFusion Builder CFML editor.

• New Feature: Hitcounts. Hitcounts can now be added to breakpoints along with breakpoint conditions. A hitcount allows a breakpoint to fire only after a certain number of breakpoint hits. For example, if the breakpoint was in a <cfloop> and had a hitcount of 5, the breakpoint would only fire on the 5th and consecutive iterations.

• New Feature: Auto-step: You can now automatically step through a CFML application, watching variables, expressions and the execution path.

• FusionDebug Rev. 3.0.1 has been tested using Eclipse Platform 3.2 to 3.5 (Galileo) on
  Microsoft Windows XP SP2, Microsoft Windows Vista SP 1. FusionDebug is a pure Java
  application with no native dependencies, and so should run on all OS platforms for which Eclipse is
  available.

• We recommend installing the Eclipse Java SDK package. This can be obtained from http://www.eclipse.org/downloads/

• We recommend also installing the CFEclipse package, which provides a capable environment for
  working with CF scripts within Eclipse. This can be obtained from: http://www.cfeclipse.org/

• Please consult the relevant Guides for quick-start instructions on getting acquainted with FusionDebug. There is
  an updated User Manual for 3.01.

KNOWN ISSUES

FusionDebug Rev. 3.0.1

The following issues are known at the time of publication.

General

• ‘Run To Line’ Causes Skip On Following CFML Code/Breakpoints With Resume/Steps

As Run To Line targets are set anywhere on a CFML page, and we expect the execution to halt at this point, the engine must be allowed to continue to the ‘next nearest’ valid CFML, and halt there. This can therefore be on another Breakpoint, causing it to seem (upon step/resume) to be skipped, where as it has simply already been hit.

• Custom Extensions Not Recognized By CFML Server

For your Custom Extensions to function you must add them to your CFML Servers known extensions. For advice on how to do this please see our user manual or web page. These contain useful links and setup instructions, as well as guides on setting your default editors. You will need to set your IDE to use editors that allow debugging on your new extensions (including the default .htm .html).

For information and instructions on use please see:
http://www.fusion-reactor.com/fd/support.cfm

CF Specific

• Custom Exceptions Fire In CF Admin/Other CF Web Applications Pages When FusionDebug Connected

This is a side effect of breaking on Exceptions, any CFML Live code running on the attached server can fire off Custom Exceptions, which FusionDebug will detect (when option selected). To use these applications during a debug session simply uncheck the option to ‘Catch Un/Caught Custom CFML Exceptions’ in the FusionDebug ‘Configuration’ Page in ‘Preferences’, from the ‘Window’ menu option. You can then re-enable the setting once you have finished using the desired page and continue debugging.

• Custom Exceptions Within CFTRY Recognized As Caught When NOT Handled In CFCATCH

When placed within a cftry/cfcatch block thrown Custom Exceptions are dealt with as Caught by CFML. Therefore even though this is Uncaught by rights, it will only be detected as caught (with this option). When this occurs the catch block will be highlighted also – due to the match not being correct. The distinction between whether ‘this’ Custom Exception, is Caught based upon the catch type is something we are working on and plan to have resolved for next Beta/Release.

Railo Specific

• FD-493/RAILO-195 Stepping is innacurate within very long pages. You may find the line cursor skips to an incorrect line, or skips back and forth, when debugging very large CFC or CFM pages.

GENERAL ISSUES

Some Numerical / Complex CF Types Decode to Java Types, Not CF Types

We’re working hard on being able to decode all CFML complex types. Most types are already
implemented – structs, arrays, XML objects, CFCs, Functions etc. In some cases, you might see
an undecoded type in the Variables and Expressions view (“… instance of …”) or a plain
string representation of the object.

Step Over sometimes requires > 1 keypress to advance the cursor.

This is because some lines of CF code perform multiple actions and require you to press
step for each action that they perform.

Step Into CFC’s is sometimes requires > 1 keypress to step into the CFC.

With the current instruction pointer located on the CFINVOKE tag, keep clicking Step Into until
the CFC is loaded. The parameters and other initialization actions are performed before the CFC
is called. You may have to push step into until this initialization is complete.

Step Requests sometimes jump around to lines of code that are not sensible.

This is a limitation of how Railo processes and optimizes pages at compile time.

Calling CFML functions which are reentrant to the currently halted thread may cause the VM to hang

You cannot set/clear breakpoints with CTRL-SHIFT-B when in the CFEclipse perspective

CFEclipse does not support the CTRL-SHIFT-B keystroke when in the CFEclipse perspective. You
can toggle the breakpoint by right mouse clicking on the line you wish to set the breakpoint
on and using the Toggle Line Breakpoint menu item.

Sometimes breakpoints don’t fire.

In the Debug configuration, make sure the Target System Type is set correctly: checked for
Windows, unchecked for Unix. And the correct connector is being used for the engine type desired.

Breakpoints set on blank lines may not always fire.

Since FD 2.0.1 breakpoints can be set on blank lines. FD cannot always get breakpoints to
fire on blank lines because they are sometimes optimized away by the CF compiler.

Wrong File Selected

When a breakpoint or step event fires, FusionDebug does its best to find the source file. If the
same file exists multiple times in different projects, the wrong one may be selected
Use the source code lookup tab on the Launch Control to correct the source code lookups.

If your system is monitored by FusionReactor with crash protection activated, FusionReactor may

terminate the page if it exceeds the Request Timeout limit that has been configured. Please
deactivate crash protection in FusionReactor.

RESOLVED ISSUES

ADDITIONAL LICENSE AGREEMENTS

This Software contains code derived from the Eclipse Foundation (“Eclipse Code”).
Such Eclipse Source Code is made available under the terms of the Eclipse Public License v1.0 which
accompanies such code, and is also available at http://www.eclipse.org/legal/epl-v10.html

Eclipse Code. On behalf of Contributors to such Eclipse Code, Intergral hereby: (1) disclaims any and all
warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability
and fitness for a particular purpose with respect to such Eclipse Code and any and all derivative works thereof,
(2) disclaims any liability for damages, including direct, indirect, special, incidental and consequential
damages, such as lost profits, and (3) represents that any provisions in this License Agreement that differ
from the Eclipse Public License under which Intergral licensed the Eclipse Code, are offered by Intergral
alone and not by any other party. The source code for the Eclipse Code as contained in this Software may be
obtained by the Licensee as described in in this Readme to the Software. Intergral provides the Eclipse Code as
is, without warranty or support from Intergral.

By installing this product, in addition to the Intergral license terms, you also agree to be bound by the
third-party terms provided to you with the Intergral product documentation. Intergral recommends that you review
these third-party terms.

Using FusionDebug with Adobe’s CF Builder

There are a number of compatibility issues when using FusionDebug installed into Adobe’s ColdFusion Builder.

The debug port

If CF Builder has a server correctly configured, and the server has the debug port open (for example, RDS is enabled), then CF Builder will connect to the port on startup. This means that FusionDebug never gets a chance to connect to the port. To prevent this from happening any RDS configurations need to be disabled. To do this go to Window -> Preferences -> Adobe -> RDS configuration, then remove any servers. Now restart CF Builder and FusionDebug should be able to connect properly.

Breakpoints

When FusionDebug is not connected, any breakpoint that is set is an Adobe breakpoint, when FusionDebug connects all breakpoints are “converted” to FusionDebug breakpoints. As long as FusionDebug is connected only FusionDebug breakpoints will be added. When disconnected the breakpoints will not be converted back and so it is actually possible for you to add a duplicate breakpoint on the same line. On another FusionDebug connect these duplicates will be resolved.

Conclusion

Overall, FusionDebug does perform well when installed on CF Builder, and there are few problems unless you are switching between the two debuggers.

Breakpoint Conditions & Hitcounts

FusionDebug breakpoints now have conditions and hitcounts, further controlling when they fire. This article will demonstrate these features.

Conditional Breakpoints

Introduced in FusionDebug 3.0, conditional breakpoints allow you to halt an application when a certain condition evaluates to true. For example, in a loop you could use a conditional breakpoint to halt when a variable equals a specified value. The condition used can be any form of CFML expression, anything that can be used in a <cfif> tag can be used as a condition. Advantages of conditional breakpoints include:

• Less time debugging; No need to step through long loops to get to a particular iteration.

• Prevents convolution of production code with debug code. To stop on an iteration or when a condition evaluates to true without conditional breakpoints you would need to add <cfif> tags to your code and set a breakpoint in the body of the tags. One of the advantages of a debugger is the alleviation of extra code for debugging purposes.

• Removes the need to disable breakpoints for some test cases, for example you might only want to stop a page on some specific input.

An Example

Given the following code:

<cffunction name="DoSomethingWithLastName">
	<cfargument name="lastname" type="string">
	<!--- Do something with last name arg --->
</cffunction>

<cfquery name="qry" datasource="test1">
	SELECT last_name FROM emp
</cfquery>

<cfloop query=qry>
	<cfset DoSomethingWithLastName(qry.last_name)>
	<cfoutput> #qry.last_name# <br> </cfoutput>
	<cfflush>
</cfloop>

Suppose we knew there was a bug somewhere in the “DoSomethingWithLastName” function, and we knew it happened when the last name of “Smith” was used as an argument. We could add a breakpoint on the line of the call to the function and set the following breakpoint properties:

This means that the breakpoint will only fire when qry.last_name equals “Smith”. If we now run the page, we see this:

The page has stopped on row 9 of the query loop, where the last_name field equals “Smith”. We can now step into the function and find the cause of the bug. Note that this is a relatively small query but could be thousands of rows. Using a non-conditional breakpoint in this scenario is time-consuming and unfeasible, plus you could end up resuming past the row that contains “Smith”.

Other useful examples of breakpoint conditions:

• isdefined(“url.length”) and (url.length + 1) gt 10. This can be used to halt the page when certain url parameters are used, in this case length > 10.

• DateCompare(yourdate, CreateDate(2009, 01, 01)) LTE 0. This will halt the page when “yourdate” is before 1st January 2009.

• http.remote_addr eq “127.0.0.1” or http.remote_host eq “localhost”. These conditions will allow another machine to request the file without the breakpoint firing. Useful if you have to demo the file to another person but don’t want to disable your breakpoints. Note, on Railo use cgi.remote_addr eq “127.0.0.1”.

Read more about Conditional Breakpoints

Hitcounts

New to FusionDebug 3.0.1 are Breakpoint Hitcounts. Hitcounts are a specific type of condition for a breakpoint separate from an actual breakpoint condition. A breakpoint with a hitcount will only fire after a certain amount of hits. This is useful if you have no variables to use in a condition.

Hitcounts can be used along with conditions to fine tune the firing of the breakpoint. For example consider the following loop over a query variable:

5: <cfloop query="qry">
6:     ... use data from qry
7: </cfloop>

If a breakpoint was on line 6 we could use a hitcount of 15 and a condition of “qry.last_name eq ‘Smith'”, shown here:

This would stop the page on the 15th row that had the last_name field equal to “Smith”

Read more about Hitcounts

Conclusion

These two features will cut your debugging time down by letting FusionDebug work for you, evaluating conditions that would otherwise need to carried out by yourself, watching the Variables or Expressions view for changes. Most modern debuggers support Conditional Breakpoints and Hitcounts because as applications become more complex, debugging them becomes more complex and in response debuggers must relieve some of this complexity. These two features and countless others do just that.

Other Articles You Might Be Interested In

FusionDebug: Feature Focus – Auto-step

Useful Links

Download FusionDebug 3.0.1 (free trial version available)
FusionDebug Feature Focus

Auto-step

New to FusionDebug is the Auto-step feature. Interactively watch your code being executed at a specified speed.

The new Auto-step feature adds even more interactivity, enabling you to view execution paths of your application, variable / expression changes and even root out bottlenecks in your code.

Using Auto-step

You can set an interval between step operations in the FusionDebug Configuration dialog shown here:

There you can set intervals for both auto-stepping into or over.

You control auto-stepping with two toggle buttons on the Debug View toolbar, shown here:

The button on the left is Auto-step Into, the right one is Auto-step Over. Only one can be toggled at any time so toggling on Auto-step Into when stepping over will cause Auto-step Over to be toggled off.

How Auto-step helps

Auto-step can be used in a number of interesting ways:

• By setting a moderately high stepping interval you can visibly watch the path of execution your application takes. This is very powerful as many bugs are simply code you think is being executed when in actuality it isn’t.

• By setting a high interval, say 500ms – 1000ms, you can watch the Variables / Expressions view and for any changes that should or should not be happening.

• By setting a low interval (lowest 20ms) you can visibly see what parts of your code are taking a long time to complete. If there are long pauses between steps (longer than the step interval you entered) you know that the line should be investigated, if need be.

• Auto-step could also be used for entirely other purposes than debugging. For example, introducing a new developer to an application and it’s code can be time consuming and consequently expensive. By using Auto-step with an appropriate interval, the developer can watch where the execution path goes and learn what is being done and where.

Other Articles You Might Be Interested In

FusionDebug: Feature Focus – Breakpoint Conditions & Hitcounts

Useful Links

Download FusionDebug 3.0.1 (free trial version available)
FusionDebug Feature Focus

This occurs when the Adobe ColdFusion Builder is installed in the same IDE as FusionDebug. To integrate with CFBuilder FusionDebug will convert Adobe’s breakpoints to FD ones, but in order for the two plugins to co-exist we only do this when FD is connected. Any Adobe breakpoints that are in Eclipse before connecting will be converted to FD breakpoints, but cannot be converted back on disconnect, therefore breakpoint toggling does not work as expected.

One way to ensure that toggling always works is by exclusively using FusionDebug methods of toggling a breakpoint, i.e. the “Toggle Line Breakpoint” entries in the ruler context menu and the editor context menu. Note, when connected any methods of breakpoint toggling can be used.