[Looking for Charlie's main web site?]

FusionDebug Part 4 - Tips and Traps

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
While the first 3 entries in my FusionDebug series of posts have been making the case for using the tool, the fact is that like any tool there are tips and traps that you'll do well to note. In this entry, I share several of these from my experience. First I'll share a few tips on using the tool, then a few on setup of the tool.

Tips and traps on Using the Tool

Favor "Step Over" versus "Step Into", when on tags/functions that don't open files

As you are at a breakpoint about to step to a new line of code, I'll recommend that you use "step over" in favor of "step into". The latter should be used only on tags like CFINCLUDE, CFINVOKE, CFC method calls, and other tags/statements that would open a new file. It allows you to follow the flow of control into that new file (opening it, and stopping at the first line of code within that file.)

Why would I recommend you do not use it on other tags and statements? Well, recall that CFML is built on Java underneath. I've found that sometimes "step into" will cause the Eclipse debugger to take a longer time while stepping through the underlying Java of a given tag or statement. Also, some CFML tags are built in CFML.

FusionDebug doesn't show you the underlying lines being stepped over in such Java or CFML files (it's configured not to by default), but the execution will take longer than if you had used "Step Over". I've found the problem happen with tags like CFDIRECTORY and CFDUMP as well as createobject() and findnocase(). When it happens, things will just seem to be hung, but be patient.

I'm stepping, but nothing happening

Related to the above, if you are doing stepping and things seem hung, for whatever reason, with nothing seeming to happen, watch for the term "Stepping" in the Stack Trace pane (at top right). That just means that it's working, and taking some time to do whatever you've asked. Simply be patient. Control should come back.

"I don't see the 'current instruction pointer' moving while stepping"

This is quite a gotcha, which threw off myself and the FusionDebug guys. In one circumstance, as I hit the "step over" and "step into" buttons, nothing seemed to be happening. The "current instruction pointer" wasn't changing. I thought it wasn't stepping at all.

I looked at the "stack trace" pane, and rather than show "stepping", it did indeed show that the execution was proceeding from one line to the next as I'd hit the buttons.

It turned out to be a problem related to my having opened the file using the file system, rather than via an Eclipse "Project". The docs explain how to open files "properly". Forewarned is forearmed.

Be careful holding breakpoints within CFLOCK or CFTRANSACTION tags for too long

You may not think of or notice this, but if you hold a breakpoint or do stepping within tags like CFLOCK or CFTRANSACTION, you could have a negative impact on other users in your environment.

In the case of CFLOCK, you could keep someone else (who's trying to obtain that lock) from being able to get that lock.

In the case of CFTRANSACTION, you could keep someone (even outside of ColdFusion) from being able to read or update the database you are updating within the CFTRANSACTION. The degree of impact will be influenced by the ISOLATION attribute you use (or its default) in the CFTRANSACTION.

If a runtime error occurs, FD will also seem to stop

Something to keep in mind is that if you find FusionDebug just seem to stop debugging, the problem may be that you've hit a runtime (or even compile time) error in the code, which will cause CF to send an error screen to the browser but will not send anything to the debugging stream that FusionDebug is watching. As such, FusionDebug will just lose its connection to the running program.

If debugging just stops, CFMX admin's "request timeout" may be killing the page

It's easy to forget that when you're in the midst of a debugging session, you're causing the page to take likely several seconds (perhaps even minutes) to run to completion. Recall as well that CFMX has an admin setting called "Timeout Requests after x seconds" which if enabled will cause ColdFusion to detect and halt a page if it takes longer than that time to execute.

Naturally, if it is enabled and you debug a page for longer than that duration, ColdFusion will intercept the request and send an error to the browser. In that regard, this is similar to the previous issue.

Something to noticed, however, is that this "timeout requests" setting is not enabled by default in CFMX 6.1, while it is enabled by default in CFMX 7. As such, this problem of timeouts will more likely happen in CFMX 7, though again either can be configured to support it. Just be aware.

You could also override this timeout setting in a given page by using the CFSETTING tag with its RequestTimeout attribute. (You can of course also affect an an entire application by placing that in the application.cfm.)

If breakpoints fail to fire as expected

If you have any other sort of problems with breakpoints firing, note that the FusionDebug folks have written a tech support article on the topic.

Tips and Traps on Setup

Beware of the impact of debugging on shared servers

Though you certainly can turn on debugging against a central shared server (such as test, staging, or even production), you should be aware of the potential impact.

As has been discussed before, when any user requests a page that's being debugged and their execution would hit a breakpoint, the page will appear to them to be hung until the debugging developer steps through the code to completion.

Beware of the impact of the JVM config changes

As discussed in the FusionDebug User Guide, in the section on setting up tool, one of the changes you make in the jvm.config file is to remove the UseParallelGC option. That change in the garbage collection process could have an impact on the running of the server.

This is one more reason to think twice about running the tool on production.

Understanding the "ports"

When you configure that jvm.config entry, another modification is to name the port that you want the JVM debugging feature to broadcast on. Of course, you want to point to a free port when you name that (you can use "telnet servername portnumber" at the command line to determine if a port is free).

But another point to note is that this port is NOT something you then use when you request pages, nor should it be specified as the value of your web server. Instead, this port number is then used when setting up the FusionDebug interface within Eclipse. All this is well explained in the User Guide.

Using FusionReactor? (Intergral's CF monitor tool)

If you are using FusionReactor, which is Intergral's CF monitoring tool, be sure to disable its "crash protection" feature, while doing debugging. The two features are not compatible.

Summary

Those are a few gotchas. I hope they help you. If you hit others, again, I recommend you check out the FusionDebug web site. They have the docs, faqs, articles, Captivate videos, and more. Most important, they offer free support at [email protected].

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Comments
Yesterday I recieved an unsolicited spam email from the folks at fusion-debug trying to sell me their product.

If they do not understand their potential audience well enough to know that most of us think spamming is not an acceptable business practice, I am skeptical of their understanding of my other business needs.
# Posted By Gus | 10/3/06 6:24 AM
Gus, I've spoken with one of the folks at Intergral on your behalf, and they're sorry to hear of this problem. Unfortunately, it's a German National Holiday today, so all parties involved weren't available to respond. They explained that the list used should only have included those who asked for information. They certainly don't want to be labeled spammers, and they hate them as much as we all do. :-) Let's wait to hear from them tomorrow. In the meantime, my contact wanted to share that they certainly meant no offense, and besides looking into what happened, will also want to implement an opt-out solution for future mailings of this sort.
Fair enough.

As a small business owner I understand that it can be a tightrope to get the word out without being perceived as overly aggressive.
# Posted By Gus | 10/3/06 5:03 PM
Gus, we sincerely apologize that you have received an unsolicited email from us. The email in question was a _very_ limited distribution and was primarily sent out to customers, people who had signed up to receive info on FusionDebug and some CFUG member emails. I assume that if you’d not signed up with is for more info on FD, then your mail must have been in the CFUG list. Again we are truly sorry for this. If you would like to send your mail address to [email protected] I will personally make sure that your mail address is removed from any lists we have.
You have no need to apologize.

In fact, let me apologize to you!

As it turns out, the email I got was sent to a mailbox of a former CFUG manager, and as he now longer is involved, that address is getting forwarded to me. I did not notice this originally.

I believe you have shown yourselves to be respectable members of the CF community, and I wish you all the best with Fusion-Reactor.

Charlie -- feel free to delete my original post ( or the entire thread ) as I would not like to see this affect Fusion-Reactor negatively on any search engines.

Steve Gustafson
# Posted By Gus | 10/4/06 4:39 PM
Glad to see this resolved. As for deleting the comments, well, if i did that some who saw the early ones without seeing these later ones could think I was whitewashing the problem. Conversely, as you say, their admirable reply and stance is worth people seeing as well. All's well that ends well. :-)
Charlie, thanks for taking the time to do the online CFUG Breeze presentation on this product. I enjoyed the presentation but have been unable to get the product to work. Brings back memories of the hassle of getting the old Studio debugger to work! I've emailed the folks at Intergral a couple times but gotten no reply, and I've gone over everything in their FAQ and double-checked my setup but my breakpoints just aren't firing. Any ideas? I thought the pricing on the product was a bit high (particuarly once you add in update subscriptions), but would still consider getting it if it worked well and was useful for my work. But the lack of support is kind of putting me off, and I certainly can't give it a good trial if I can't even get it to run!
Just a quick followup...seems there were some problems on both ends with my support emails going through and receiving their responses but we've gotten that straightened out now and they've been very helpful in working through my setup issues so far. Still not up and running yet, but I hope to be very soon!
Well, still having some trouble getting the debug to work in Eclipse, the breakpoints appear to be firing now since the page execution does hang. But no threads/variables/etc show up in Eclipse and it does not open the file and jump to the breakpoint as it should. It's nighttime in Germany now so any ideas in the meantime?
Mary Jo, glad to hear that the communications with Intergral support got figured out. My experience has been that they're great. Until the morning (and their getting back to your), here are some thoughts.

As for the file not opening, you did say that you saw the page hanging, so clearly a breakpoint has been set and detected. Here are some tricks:

If you view the stack trace in the top left, that will show if it's breaking, and what line. You can double-click on that (as I showed in the demo, though you may have missed it). That will open the file and perhaps then you'll be able to proceed with breaking.

If the "search for duplicates" is not on (discussed in their Guide), then it may open the wrong file by default. Be sure double check that.

As for it breaking in the first place, you must have set a breakpoint at some point. If you view the breakpoints pane and double-click whatever you think is stopping the page, that will open the file to that line of code.

Let me know if that helps at all. I do ultimately want to direct people to the FD support guys, but given the time-zone difference, I'm happy to help in the meantime here.
Hi Charlie, thanks for the comments and ideas. I know how frustrating it can be sometimes trying to do good support with all the spam filters and such these days getting in the way, so was glad to see their support is indeed as responsive as you have indicated.

As for my breakpoints, I'm not getting any stack trace at all (that's what I meant by no threads showing up). My breakpoints are listed on the tab and do open up if I click on them, but no trace is showing up when I execute the page in my browser, even though the page execution does halt as expected. The tool does work with the built-in CFMX web server, I assume? Not sure what else to check at this point, but I appreciate your ideas.
Thanks to some excellent help from the folks at Integral, we were able to work out the problem. It turned out to be an issue with the CF server optimizing away the line I was trying to break on. They mention this in their FAQs, but in terms of comments and blank lines and it was a cfparam I was breaking on. It definitely was a cfparam that should be getting set at that point, so it really didn't occur to me that this might be happening. And the first time they've run across that as well, so I expect they'll be adding it to the FAQs. I know I had tried breaking on another line or two, but not sure if that was after I got the other issue with connecting worked out or not.

Another thing I think could be really valuable with this tool is to double-check that you've scoped your variables in CFCs properly. It separates out the local function variables from variables scope, making this very easy to check. Particularly valuable if you load CFCs into application or session scopes where failing to use local scope can create serious issues.
That's great to hear, Mary Jo. I've really found the guys to be outstanding in helping resolve problems.

As for the lines being optimized away, in their defense (and even if they didn't mention it) I will point out that they have long allude to that issue (beyond just blank lines) in their support FAQ at http://www.fusion-re..., where they say:

"Please note that there are a couple of CF tags such as cfscript or cfreturn which can also be optimised away resulting in breakpoints on these lines not firing."

As you say, though, they could add CFPARAM to that list.

As for your observation about using the tool to detect variable scoping issues, good thinking. Thanks for all your feedback here.
Well, the other reason I didn't make the connection was because I assumed the breakpoint *was* firing since the page execution was halting...and if I toggled all the breakpoints off, it did continue. So not sure this really was the same issue that their FAQ mentions....and was another reason I did not make the connection.
Yes, great point. I have to admit I was wondering that in the back of my head. Oh well, it's sorted out now. Again, as the product (and docs and support) evolve, I'm sure such issues will eventually become much more easily recognized and resolved. Until then, they're there to help. Cheers.
Indeed, that's the important part. I'll continue to play with it a bit and see if I can get a better idea of exactly what was happening.

Thanks for your help and comments Charlie!
It definitely seems to be an issue different from the breakpoints not firing. If I set a breakpoint on a comment or blank line, it just skips over them as the documentation mentions. In this case, they appear to be firing, but no stace trace is created. It happens not just with the cfparam line, but also with a cfsilent line before it. The first line in my code that seems to correctly trigger the stack trace is a cfset line that follows the cfparam. So not sure exactly what is causing it, but hopefully it will be useful if anyone else runs into the same problem.
Thanks. So to help people get what this is all about, you're saying that you find you can set a breakpoint, and a request for that page will appear to be being debugged (it hangs) but you never see the stack trace reflecting that it's stopped, nor then can you do stepping. Is that right?

And the answer for you has been to move the breakpoint to subsequent CFML statements (tags, cfscript statements, variables between CF tags, or otherwise) until it shows it breaking, right? And to get it to "find that", since you can't do stepping, I imagine you need to terminate the request and rereun it. Is that right?
Correct on all points.
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting