Blog | FusionDebug - Part 4

Users installing FusionDebug into a Mac OS X installation of Eclipse 3.5 (Galileo) utilizing the Cocoa SWT widget system may experience slow performance when stepping.

This will be reflected by a short delay between the Debug view updating its contents and the relevant source file and line being displayed in the editor.

We have isolated this as an issue in the Cocoa SWT build, and as such is unfortunately out of our control. The SWT (Standard Widget Toolkit) is the component of Eclipse which provides the buttons, menus and other visual components.

This problem has a slight impact on stepping speed. If you are affected by this issue, we recommend you obtain the Carbon build of Eclipse for Mac OS X which does not exhibit this issue.

You can find all Eclipse builds for Eclipse 3.5 ‘Galileo’ here.

Pages using CFTHREAD sometimes leave stack frames visible in Eclipse, even after the page has completed.

When stepping through code against a ColdFusion 8 engine, you might see the stack frames continue to be displayed even though the page has resumed normally.

This occurs only on pages using CFTHREAD, and even then, only occasionally.

The problem is understood and is due to how the CF8 server completes the page, on these occasions. Unfortunately no fix is available at this time. We may re-evaluate this issue for a future release.

FusionDebug has a complete IDE installer packages for Windows, MacOS, Linux and Solaris which include and configure Eclipse,CFEclipse and FusionDebug. These installers are the fastest way to get started with FusionDebug. Use these packages if you do not have an existing installation of Eclipse, CFEclipse, Flex Builder or FusionDebug.

FusionDebug also has Plugin installers that allow you to install FusionDebug and optionally CFEclipse into an existing Eclipse or Flex Builder installation. You should use the plugin installers when adding FusionDebug to your existing Eclipse / Flex Builder installation.

There is also an Eclipse update site available.

These files and associated instructions can be found on the Downloads page.

Error

“Windows could not start the CF MX7 Server on Local Computer…refer to service-specific error code 2.”

The problem is likely to be that the jvm.config file still contains some advanced garbage collection options such as : -XX:+UseParallelGC

See related technotes for further details, as there could also be other garbage collection options in the file that may need removing.

The issue may also be that one of following has occured;

• ColdFusion (Jrun) is still running. You can check this by looking at the processes in task manager.If you see a process called jrun.exe or jrunsvc.exe you need to end the processes, and then restart CF. Don’t forget to check on “Show all processes”
• Port 8000 is already in use:
  • 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
• The dt_socket transport is not available. Please confirm this by following the same steps under point 2.

Also check to see that the dt_socket .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. This can be solved in one of two ways;

1. Add C:/CFusionMX7/runtime/jre/bin to your windows PATH variable
2. Copy dt_socket.dll to a folder in your windows PATH (e.g. C:\CFusionMX7\runtime\jre\bin)

NOTE: The dt_socket.dll is given only when requested. To make a request contact

Problem:

• Breakpoints don’t fire at all
• Breakpoints don’t fire in CFM/CFC pages in subfolders

Two of the most important options in FusionDebug are Webserver Folder, and Eclipse folder structure mirrors webserver. This article discusses how to configure these options in detail.

FusionDebug uses the information in the Configuration Dialog (accessible from the Run -> Debug menu) to accurately set breakpoints. If the information in this dialog is not configured correctly, FusionDebug may report that a breakpoint has been set, but it never fires: the associated page always runs to completion.

Solution:

In most cases, this problem can be solved by correctly configuring the Webserver Folder and Eclipse folder structure options in FusionDebug. Once these options are correctly configured, the configuration usually doesn’t need to be subsequently changed.

FusionDebug needs to know exactly where on your ColdFusion server the files are located, and how folders are structured. It uses these options, together with your Eclipse folder structure, to accurately set breakpoints and select the correct files when breakpoints fire.

Webserver Folder

This is the folder where you store your CFML files on your ColdFusion server, and from where they are run by ColdFusion.

The following image shows the web server root for the TestProject application:

Unable to render embedded object: File (support-bpdf-rootfolder_1.5.gif) not found.

c:\inetpub\wwwroot\TestProject is entered into the FusionDebug configuration in the Webserver Folder field:

Here are two images showing the Project Explorer in Eclipse, with the Test Project open, and the Properties for that project. You can see the project has been set up to point directly within the webserver folder.

TestProject in the Project Explorer

Location of TestProject in Eclipse

Eclipse folder structure mirrors webserver

This setting tells FusionDebug whether the folder layout inside your Eclipse project mirrors the files which are actually served by ColdFusion.

This setting is important for FusionDebug to be able to accurately tell when a breakpoint has fired. The following graphics illustrate how this option can be set.

Either…

Eclipse project has same structure as webserver… check this option

Or…

Eclipse project has structure but webserver is flat… uncheck this option

Problem: When a breakpoint fires or I’m using the stepping commands, FusionDebug sometimes finds the wrong source code file.

FusionDebug uses the source tab in the Configuration dialog to find any source code it needs. By default, this tab contains all projects in the workspace, and is configured to stop looking for source code when it finds a matching file.

If you have the same filename in two or more projects, FusionDebug will pick the first one it finds – which may not be correct.

This behaviour is easy to change.

Changing Source Lookup Behaviour

• Open the Configuration dialog and select the configuration you’d like to edit.
  Open Run -> Debug, open the FusionDebug element and select your FusionDebug configuration.
• Either
  1. Select Search for duplicate source files on the path.
     This will make FusionDebug find all the matching files, and ask you to pick the right one every time it finds duplicates.
  2. Edit the source lookup path manually.
     Instead of looking in all Eclipse projects, you can fine tune the search areas to include only your current project, or a small collection of projects. See the next section for more information on using this functionality.
• In either case, don’t forget to click ‘Apply’, and re-start your debugging session to make the change visible.

Editing the Source Lookup Path

By default, the source lookup path contains all workspace projects. You can change how the lookup path works by adding or removing projects from the path, or changing the order in which the path is searched.

The following screenshot shows a default source lookup path.

The projects CF_VideoStoreApplication and FDB_TestFiles both contain a testfile.cfm, but only the FDB_TestFiles one has been distributed to the web server, since that’s the application we’re debugging. Since the source lookup path is unchanged from the default, FusionDebug will pick the first one in the list – that from the CF_VideoStoreApplication – which is incorrect.

We can solve this by checking the box marked Search for duplicate source files on the path. Now, when FusionDebug tries to find the file, it asks us which one is correct, by popping up the following dialog:

This is a good solution, but being asked every time can be a bit time-consuming. Instead, we can edit the source lookup path to include just the project we need. The source path is specific to each configuration, so if we were debugging another project, we could simply add a new configuration, and set up the source path for that project too. More information on creating configurations can be found in the User Manual.

We can’t edit the Default element of the source path, since Eclipse maintains that automatically. We can remove it though. We click on the Default element, and select Remove. This removes the default element completely, leaving an empty source path.

Now we select Add. The Add Source (Selection Needed) dialog appears, listing all resources available in the workspace.

We select Project and put a check-mark against the FDB_TestFiles project, then click OK. This adds the FDB_TestFiles project to the source path. We click Apply and, since FusionDebug is not connected, Debug.

Now whenever the breakpoint fires in testfile.cfm, FusionDebug opens the correct one without asking – that from the FDB_TestFiles project.

Conclusions and Further Exercises For The Reader

We’ve created a custom source lookup path for our configuration. This ensures that FusionDebug is able to find the correct source file whenever a breakpoint fires. It’s particularly important to do this since many projects share common files, not the least of which is application.cfm.

Some development organisations may also have common libraries of CFCs or pages which they re-use. It would be a simple matter to create an Eclipse project for these common libraries, and then to include it in the source lookup path too.

Careful ordering of path elements (using the up and down buttons) can help FusionDebug quickly locate the right file without having to turn on Search for duplicate source files on the path.

Problem: My breakpoints don’t fire.

In order to set breakpoints accurately, FusionDebug needs to know about the layout of files on your web server.

There are three settings which must be set accurately for breakpoints to fire, and they’re located in the Connect tab of the Debug Configuration dialog.

• Webserver Folder
  This setting tells FusionDebug where the files are located on your web server. This should be the path to the web root as seen by the web server. This setting doesn’t take into account mapped drives or network connections, and should use local (to the server) drive letters, if necessary.
• Eclipse folder structure mirrors webserver
  This setting tells FusionDebug where to find the pages on the server. You can find more information on setting this option correctly below.
• “CF Server is on Windows”
  This option should be checked if the CF server is running a Microsoft Windows operating system (Windows 2000/XP etc.) For Unix and Unix-like operating systems (Linux, BSD, MacOS X etc.), uncheck this option.

More on Folder Structure

If you are debugging locally, and have configured your Eclipse project to use the same files that are served by the web server, this option should be checked.

Otherwise, use the two rules below to set this option.

• Eclipse source in folder structure and web server has same structure OR Eclipse source in single folder and web server in single folder:
  • Check this option
    Eclipse source in folder structure and web server in single folder
  • Uncheck this option

Troubleshooting Breakpoints

You might find the following steps helpful if you are having problems making breakpoints fire in your environment.

1. Use the Debug View to make sure you have connected to the same machine you’re running pages on in your browser. The Debug View shows this information as the second item in the tree (e.g. “FusionDebug (localhost:8000)”).
2. Make sure the page you’re running, and the parameters passed to it actually would cause the breakpoint to fire. Consider the flow of control through if-else tags. Has the page already completed or aborted before the breakpoint?
3. Make sure the breakpoint is enabled (shown by the presence of a check mark in the box by the side of the breakpoint in the Breakpoints view)
4. Make sure the Skip all breakpoints option is not active. This can be checked by looking at the status of the Skip button in the Breakpoints view (the blue circle ). If Skip is active, all breakpoints – both in the Breakpoints view and in individual editors – will have a line through them.
5. Carefully examine the options in the Debug Configuration
   • Is the Webserver Folder set correctly? Are the drive letters from the point of view of the server?
   • Is the option CF Server is on Windows correctly set? If you are running on any Unix or Unix-like platforms, this check mark must be cleared.
   • Is the Eclipse folder structure option correctly set? You might try toggling this option to see if it helps.

The likelihood of this problem is caused by the Source Tab on the launch configuration being incorrectly configured. The source tab must be mapped to the project that contains the source files, or to the default (which is all the projects). If the project that contains the source code is closed, FusionDebug can’t tell Eclipse to highlight the code. Take a look at the following support articles and check to see that the source tab is correctly configured for your project:

FusionDebug 1.0 Finds the Wrong Source File
Setting up a Debug Configuration in FusionDebug

These platforms can be debugged by ensuring the location of the components on the server is entered as a mapping in the Source Code Lookups tab of FusionDebug’s Launch Configuration.

Ensure the Source Code Lookup page contains an accurate mapping which mirrors the layout of your code on the server. This can be verified after setting the Lookup by setting a sample breakpoint, and ensuring the Server File text in the Breakpoints View reflects the exact location of the file on the server.

For more information on configuring FusionDebug, please see the support article Setting up a Debug Configuration.

You may have problems with how you’ve configured your FusionDebug setup. See this support article for how to correctly configue FusionDebug.
One of the features mentioned there is an option called “Compile CF page in debug-friendly mode.” This is the default but if you have a problem it would solve, you have to recompile the affected templates while you’re debug-enabled. That means you need to open and change the file (even if that means just entering a space and removing it) and then save it so that the next request for the page will recompile it.

Another issue is that if you’re configuring debugging against a server that’s not your local machine, be careful when configuring the “web server folder” in the “connect” tab since the value for the location of the Web server files should be relative to that Web server (not relative to your local machine, such as if you use a mapped drive locally).

Another possible problem is if you set a breakpoint on a line that doesn’t contain CFML tags or expressions. Eclipse won’t prevent that, but execution won’t break on that line. Relative to that, the breakpoint line numbers are fixed and static. If you change the file to add or remove lines, the breakpoint line number(s) may now be incorrect, which could cause the problem above (or the breakpoint may now be on a CFML line that doesn’t execute). As of FusionDebug version 2.0.1, these breakpoints may fire. Consider upgrading to FD 2.0.1.