The Step Out (Step Return) functionality is only active on pages with multiple stack frames, i.e. pages which have called CFCs or sub-tags.

This bug appears on the Eclipse 3.2.0 platform. The bug does not occur on Eclipse 3.2.1 or 3.1.2. In order to Step Return, the top-most stack frame must be clicked. This will re-enable the functionality.

We recommend upgrading from Eclipse 3.2.0 to Eclipse 3.2.2 to solve this issue.

This is a known problem. Due to platform changes between Eclipse 3.1 and 3.2, we can’t currently support Inspect on 3.1. We recommend upgrading your Eclipse installation.

If stepping is very slow when you are debugging try closing the Variables in the variable view, and the expressions in the expressions view. Also try just selecting the breakpoints and stepping while only the breakpoints are visible. FusionDebug must fetch all of the variables and expressions that you have open every time you step and this can slow things down.

If things are going slow when you step into certain tags, i.e. they go slow when you step into a <CFDUMP>, then try using STEP OVER instead of STEP INTO. Some of the ColdFusion tags are implemented in ColdFusion code and a lot of Java. If you step into them instead of stepping over them, we will detect it, but you must wait for the debugger to step through all of this code until it returns to the next piece of real (your) CF code.

Other reasons why this is occurring could be;

1. Memory is very tight.

The debugger requires some memory (not much), but if memory was particularly tight, it may move Java into a exhausted memory condition. If this is the case Java can slow down by 100’s to even 1000’s of times. To check this, try increasing the -Xmx setting in your jvm.config. eg, if the settings is -Xmx512m then try -Xmx768m

2. Garbage collection is taking a very time

When the debugger is active garbage collection is slowed down, so that objects are available so that you can examine them. This could cause the server to go slow periodically for a few seconds. Does your page create use a lot of memory?

It is possible to inspect and drill through CFC objects held as variables. However, issues of this not working when CFCs are addressed via gateways sometimes exist. A workaround for this has been developed, a request for a patched JAR file can be done so by contacting .

The JAR file is installed as follows;

1. Shut down Eclipse
2. Go to the Fusion Debug Core plugin directory, typically C:\eclipse\plugins\com.intergral.fusionreactor.debug.core_1.0.0
3. Rename the file core.jar file to core.bak
4. Place the attached Jar file in the folder as core.jar
5. Start Eclipse and retest CFC’s to see if they now open correctly.

This problem is fixed in FusionDebug 2.0

Yes. FusionDebug will work with any ColdFusion application or framework and has been tested with Mach-ii, Model Glue, MGU, Coldspring, Transform, Fusebox and many others.

FusionDebug is not limited to working on files in the same folder. For FusionDebug to be able to find the files in sub-folders your Eclipse Project folder structure must match (mirror) the folder structure on the web server, and you have to have the “Eclipse folder structure mirrors the webserver” option checked ON (default) in the FusionDebug Launch configuration.

Please note that FusionDebug 2 has enhanced source code lookup features and can handle far more complex applications than FusionDebug 1.0

After a clean installation of FD Standalone a dialog shows when starting FD saying:

“A Java Runtime Environment (JRE) or Java Development Kit (JDK) must be available in order to run FusionDebug. No Java virtual machine was found after searching the following locations: C:\Program Files\FusionDebug\jre\bin\javaw.exe ‘javaw.exe’ in your current PATH”

This is a known bug and has been fixed in version 2.0.1. To fix this bug for the current version of FD add the directory:

C:\Program Files\Common Files\i4j_jres\1.6.0\bin

to your PATH variable.

Note: The above path is depended of the language of your Windows. For a German Windows this directory is:

C:\Programme\Gemeinsame Dateien\i4j_jres\1.6.0\bin

For other languages there might be a different path as well.

The FusionDebug Configuration settings allow you to enter the IP address of the server that you wish to debug. If the machines that you have are load balanced then you have to enter the private IP address of the server. By doing this, you’ll be able to create as many debug profiles as you like by copying the profiles and altering the settings on them to meet the setup of each environment.

The jvm.config file would have to be altered for any server that you wish to debug to include the debug settings also. eg. you may have to add the following options to your java.args:

-Djava.compiler=NONE -Xnoagent -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000

Please note that the address is the port number that you must enter in the launch configuration. You cannot have more than one server using the same port. See the related technotes for futher details. Also see the Adobe technote on configuring individual JVM settings for each JRun Server

Also note that only one person can connect to a server to debug at any one time (this is a restriction of the underlying Java JVM).

These threads have suspended because of a breakpoint. Breakpoints fire whenever a request hits them. If you see many pages in the Debug View, this is because a web browser requested that page, and the page hit a breakpoint.

If you have a shared test server, we recommend disabling your breakpoints, or activating “Skip All Breakpoints” (see “Breakpoints View” in the User Guide) after your breakpoint has fired, so requests from someone else do not suspend. You can then resume any requests that may have suspended from others.

FusionDebug doesn’t require pages to be launched ‘inside’ the debugger. Simply run your page using a web browser (or Flex, Flash Remoting, Ajax, or web service client) as normal and the debugger will suspend it correctly when a breakpoint is hit.