Technotes

This is due to a Java bug (6497210, available here, fixed in Java JRE/JDK 7.0b7) which causes Java (on which ColdFusion runs) to crash during debugging. This bug may manifest itself by:

• a simple exit of the Java Virtual Machine (if running in a Unix console or DOS Window),
• the Windows ‘ColdFusion MX [7] Application Server’ service spontaneously stopping,
• on Mac with a standard Mac OS X ‘Crash Reporter’ dialog

All of these exits may also be associated with a VM error message “Bus Error”.

This problem occurs if a debug client (such as FusionDebug, Eclipse, Netbeans or JDB) is reading variable values when Java attempts to clean up memory by performing a garbage collection.

On Windows, a Java Error File (hs_err_pidXXX.log) may be generated in the ColdFusionMX/runtime/bin folder. On Macintosh, a Crash Reporter log may be generated in the ~/Library/Logs/CrashReporter folder.

This problem occurs quite rarely, but could happen when performing fast stepping (by holding down the Step-Into or Step-Over key). The problem affects all Java platform debuggers, not just FusionDebug. Running in low or marginal memory situations will also greatly increase the probability of this bug occurring.

The bug occurs much more frequently on non-Windows platforms.

If you are affected by this behavior, it may be possible to alleviate the problem somewhat by increasing the memory available to Java, thereby decreasing the number of garbage collections required and the possibility of one occurring while FusionDebug is reading variables. The following procedure details this workaround.

• Either (ColdFusion Standalone Only)
  • Open the CF Administrator
  • In the Server Settings menu, select the Java and JVM option.
  • Increase the value in the Java Maximum Heap Size field, bearing in mind the total amount of memory available on the machine.
  • Click ‘Submit Changes’
  • Restart ColdFusion.
• Or
  • Stop the ColdFusion service.
  • Locate your JRun Java configuration file jvm.config.
  • Make a copy of this file and move the copy to a safe place. You may restore this copy in the event of problems.
  • Open the original jvm.config
  • Locate the line java.args, and within it the -Xmx option. This option tells Java how much memory to use. This line is very long – be careful not to introduce any carriage returns.
  • Increase this number, bearing in mind the total amount of memory available on the machine. E.g. to allow 500 megabytes for Java, use the option -Xmx500m
  • Save and close the file
  • Restart the ColdFusion service.

This bug has been fixed in Java version 7 (1.7), but since neither FusionDebug nor ColdFusion/JRun are supported on that platform yet, we recommend performing the workaround procedure above. There is a chance the fix will be back-ported to future Java 5 (1.5) and 6 (1.6) maintenance releases, though this is not guaranteed by Sun.

If, after performing the remedial steps above, you are still affected by this problem, please get in touch with us at Support.

From the Eclipse Window menu, select the Show View -> Navigator. This will add a navigator view to your debug perspective which you can use to open projects and select files.

Alternitively, use the all-in-one FusionDebug perspective: select Window -> Open Perspective -> Other, then select FusionDebug. We’ve created this perspective to contain all the most useful views for debugging. Of course, you can customize this perspective yourself and add or remove views as you see fit.

Compilation of pages occurs before FusionDebug can start tracking the page as it runs in ColdFusion.

Having FusionDebug connected does not affect this process.

If the page does not compile, ColdFusion will report errors as if the debugger were not connected – you will be able to read the normal error report in your browser, as usual.

If an error occurs during page execution or stepping, ColdFusion will process that error as though the debugger were not connected.

FusionDebug will stop tracking the thread, and you should refer to your browser for any debugging or robust debugging report generated by ColdFusion.

Eclipse requires the double-quote (") characters in the expression to be specified in the Find, or at least covered by wildcards.

Since all expressions are enclosed by double-quotes, they must be specified in all Find operations. E.g. the expression "thedate" must be specified using wildcards (*date*).

FusionDebug attempted to evaluate the expression, but either:

• it didn’t return a value (for function calls), or
• one or more of the variables or functions referenced by the expression was not available at the current debugger position.

In the latter case, the expression will be correctly evaluated when all the components comprising it are visible (using normal ColdFusion visibility rules) from the current position of the debugger.

No expressions are evaluated unless a thread is currently paused. Clicking on a frame within the Debug View causes the expressions to be evaluated in the context of the instruction pointer in that frame.

This is a known issue when debugging on the JRockit platform.

Currently the only solution is to change to a different JVM.

This is a confirmed fault with the Eclipse 3.1 platform. You may see this error if you are using Eclipse 3.1, or Flex Builder 2 (“Flex 2”), which also uses this platform. The fault is confirmed in Eclipse platform bug 105095

We recommend updating to Eclipse 3.2.2 or newer.

Text output by the cfoutput tag is buffered by ColdFusion until

• the page completes, or
• the buffer fills,
• or a cfflush tag is executed.

If you’d like to output data as you are debugging, try inserting cfflush tags periodically or use the cfflush interval attribute to cause flushing after a certain number of bytes

FusionDebug can only step into CFCs, cfinclude pages, sub-tags or modules. FusionDebug can’t step into Java objects or ColdFusion internal tags.

Additionaly, ColdFusion sometimes performs optimization around sub-tag calls, which can lead to this functionality not working, or requiring one or more additional clicks on the ‘Step Into’ button to take effect.

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.

Here is an outline of how to get started quickly debugging. It is recommended to read the FusionDebug manual to get further information about debugging ColdFusion:

• Create a New FusionDebug Launch (Select the Run->Debug… menu and right click on FD, select New)
• Enter the IP address of the server
• Select the mappings table and enter a mapping to tell FD where the Eclipse code is placed on the CF server
• Click Debug on the Launch Configuration
• Go to the FusionDebug Perspective
• Set a breakpoint on a line of CF code (double click in the ruler next to the line of code)
• Run your page in a web browser
• FusionDebug should hit the breakpoint and highlight the line of code
• Press Step Into (F5) or Step Over (F6)
• You’re debugging!

This can be caused by one of two things. You can check this by starting ColdFusion from the DOS command line.

• The port configured in the jvm.config (default: 8000) is already in use. Please try a different port. If this does not help, it could also be that multiple servers are trying to start at once; please see this the linked technotes.

• dt_socket.dll cannot be found. FusionDebug needs to connect to a debug transport called dt_socket. Could you please confirm for me that dt_transport.dll is in the folder C:/CFusionMX7/runtime/jre/bin. If it is then the C:/CFusionMX7/runtime/jre/bin folder is not being picked up by your windows path. You could solve this in one of two ways:
  • Add C:/CFusionMX7/runtime/jre/bin to your windows PATH variable
  • Copy dt_socket.dll to a folder in your windows PATH (e.g. C:\Windows)

Starting CF from the DOS Command Line (make sure the CF Service is stopped first):

• Open a DOS window
• CD to C:/CFusionMX7/bin
• Type: cfstart
• ColdFusion should start and you should get an error message if it doesn’t

This is a known problem with Eclipse 3.1 and doesn’t occur in 3.2. We recommend you upgrade your Eclipse Platform. As of writing, the Eclipse 3.2 version of Flex Builder 2 is only available as a plugin.

There are several ways to remove a breakpoint.

1. Double click directly on the breakpoint
2. Right mouse click on the breakpoint and select the Toggle Breakpoint Menu item
3. Click on the line in your code which has a breakpoint (actually on the line, not in the border) and then Right-click and select “Toggle Line Breakpoint” from the menu.
4. Open the Breakpoints tab, right click on one of the breakpoints listed and select Remove from the menu.

Also note that you can disable breakpoints on the Breakpoints tab by right mouse clicking on the breakpoint and selecting the Disable option. This causes the breakpoint to no longer fire, but the breakpoint definition is kept in the breakpoint tab so that you can Enable it again later, without having to find the location in the code and reinserting the breakpoint.

“Perspectives” is the name Eclipse gives to different window layouts.

The Debug perspective contains a layout optimized for debugging code such as Java. The FusionDebug perspective has been optimized for debugging ColdFusion applications.

You typically change to the FusionDebug perspective when you start a ColdFusion debugging session, and change back to an Editing perspective such as the CFEclipse perspective when you are writing code.

You can change perspective by selecting the Windows->Open Perspective menu option.