Twitter: raymondcamden


Address: Lafayette, LA, USA

A highly unusual ColdFusion arguments error

02-26-2013 3,779 views ColdFusion 18 Comments

This one is weird. I don't mean kinda weird. I mean bat-crap insane what-the-hell type weird. Earlier today Jeremy Tan sent me some code that acted a bit odd. Let's take a look at it.

In the code snippet above, you can see some data being passed to a CFC within a transaction. Note - there are no actual database calls here, but that doesn't matter. The CFC is simply doing a dump of the Arguments scope:

Now let's look at the output. There should be 6 dumps from the set() call and one in the middle for test2.

Um... ok. We have 8 dumps. We don't have the dump of test2. Also note the third dump, which should have "Bob in line 2", has it as 9. Oh, and even better, i is 2, not 3.

Things get weirder if we simplify. I commented out everything but the last two calls:

Yep, three dumps. Here is where things get even more weird. Jeremy found that if he simply stopped using named arguments and switched to ordered ones, everything worked fine.

If there was a bug with the data being displayed (oh wait, there is that too), then I'd maybe think it made sense. Again, as a bug. But the additional calls just don't make sense at all.

Obviously this is could be really bad for anyone doing CFC calls inside a transaction. You can find Jeremy's forum post on the topic here: Weird transaction issue with implicit struct (and possible array). I've also asked him to fill out a bug report and post the link here.

18 Comments

These comments will soon be imported into Disqus. To add a comment, use Disqus above.
  • Dave Oram #
    Commented on 02-26-2013 at 7:42 PM
    Well done Jeremy. Wish I had know this a few days ago.
  • Commented on 02-26-2013 at 7:46 PM
    Did you actually run into this too?
  • David Mitchell #
    Commented on 02-26-2013 at 7:46 PM
    found the bug: https://bugbase.adobe.com/index.cfm?event=bug&...

    i have been struggling with this for a while now. Good to know that I am not the only one.
  • david oram #
    Commented on 02-26-2013 at 7:47 PM
    Yeah - seen it recently - wierd eh!
  • Commented on 02-26-2013 at 7:49 PM
    Wow, ok. Well, glad he found it and I'm glad I'm helping spread the word then. ;)

    David - thanks for posting the bug link.
  • Commented on 02-26-2013 at 7:50 PM
    I added a note to the bug saying it happens in 10 as well.
  • Commented on 02-28-2013 at 1:33 PM
    The repro case can be pared back much further than this:

    <!--- repro.cfm --->
    <cfscript>
    o = new C();
    transaction {
       a=1;   // any statement at all
       o.f(arg1={key1="value 1"}); // only a problem with named args & struct-literal notation
    }
    </cfscript>

    // C.cfc
    component {

       function f(){
          writeDump(arguments);
       }

    }
  • Commented on 02-28-2013 at 1:34 PM
    Blimey. And it's not just a transaction{} thing, it seems it's ANY block-level construct. This also does it:

    <cfscript>
    o = new C();
    try {
       a=1;   // any statement at all
       o.f(arg1={key1="value 2"}); // only a problem with named args & struct-literal notation
    }
    catch (any e){
       
    }
    </cfscript>
  • Commented on 02-28-2013 at 1:37 PM
    Damn. Adam, please be sure to add a note to the bug report. This is pretty darn big. Does if{} also have the bug?
  • Commented on 02-28-2013 at 1:38 PM
    Indeed it doesn't even need the CFC:
    <cfscript>
    try {
       a=1;   // any statement at all
       f(arg1={key1="value 3"}); // only a problem with named args & struct-literal notation
    }
    catch (any e){
       
    }

    function f(){
       writeDump(arguments);
    }
    </cfscript>
  • Commented on 02-28-2013 at 1:39 PM
    Yes, it's with if() too. Bloody hell.

    <cfscript>
    if(true) {
       a=1;   // any statement at all
       f(arg1={key1="value 3"}); // only a problem with named args & struct-literal notation
    }

    function f(){
       writeDump(arguments);
    }
    </cfscript>
  • larry c. lyons #
    Commented on 02-28-2013 at 3:03 PM
    A question, does this just happen with script based code or with the more traditional tag based stuff?
  • Commented on 02-28-2013 at 3:05 PM
    What did you see when you tried it Larry? ;)
  • larry c. lyons #
    Commented on 02-28-2013 at 3:17 PM
    I'll have to try it this evening. These people here actually expect me to work. The nerve!
  • Commented on 02-28-2013 at 3:18 PM
    Heh, bastards! ;)
  • Louis #
    Commented on 03-01-2013 at 3:37 AM
    Wow! This is fascinating. Has anyone checked CF<10 or Railo?
  • Louis #
    Commented on 03-01-2013 at 3:42 AM
    @ larry - Tags don't seem to be affected:

    <p>CFScript</p>

    <cfscript>
       try {
        a = 1;
        f(arg1={key1="value 3"});
       }
       catch (any e){}
       
       function f(){
        writeDump(arg1);
       }
    </cfscript>

    <p>Tag Based</p>

    <cftry>
       <cfset a = 1>
       <cfset f2(arg1={key1="value 3"})>
    <cfcatch type="any">
    </cfcatch>
    </cftry>

    <cffunction name="f2">
    <cfdump var="#arg1#">
    </cffunction>
  • Bill Davidson #
    Commented on 03-07-2013 at 10:17 PM
    Yeah - Larry. Back to work. Why would you be using tags anyways? :)

    Seriously - this a pretty big issue. I wonder if I have hit this before and just thought it was me!