Getting another 500 null

[CFGumby]

Hello,

  we are having a weird problem that just popped up.  We are getting a 500 null.  I'm not new to these having been a CF programmer fo 12 years but this one really stumps me.  Here is the basics.

Program1 includes Program2

Program2 includes Program3

Program3 includes Program4

Program4 cfexits (exittemplate) back to Program3

Program3 cfexits (exittemplate) back to Program2

Program2 ends and Program1 continues until it hits a cflocation to Program5 which is a landing page.

The cflocation does not execute and at that point we get the 500 null.  I've had the programs send e-mails to myself just before the cflocation and at the beginning of Program5 and I get P4's e-mail but not P5's.

Now here is something interesting, there is a function in Program4 that gets executed just before the cflocation and if I add a cfflush in it, the cflocation, even though everything I've seen and read is not supposed to work, it does work and we don't get the 500 null.  Also, in Program3 there is a cfsilent.  If I comment it out we don't get the 500 null.

Determined to figure this out, I continued to debug and I added cfaborts in several key places.  If I add a cfabort in Program1 anywhere below the cfinclude to Program2 and above the cflocation, I get a 500 null.  Just as an fyi, my cfaborts alway include <cfoutput>xyz</cfoutput> so they are easy to find and remove.  If I add a cfabort prior to the cfinclude to Program2 or anywhere prior to the cfexit in Program3, I see my cfabort.  I think that may be relevant because to me it appears to be a displaying issue of some sort.

Other notes, everything seems to have run and updated just fine prior to the 500 null.  The include to Program2 is within a cftransaction but the cflocation is not.  (Removing the cftransaction did not have an effect.)  Currently this happens on two servers, our Dev and Test servers.

I'm going to continue debugging since this is an important process to our business.  If anyone has any ideas I'd be happy to hear them.

Thanks in advance.

[BKBK]

My initial instinct: a page is being opened, or a code procedure is being run, ad infinitum. A common cause of this is a cflocation tag in Application.cfc/Application.cfm.

[CFGumby]

Hello,

  I don't think that is our case here.  We are careful not to put cflocation's in our Application.cfm.  Since my last post, I've found out that the error occurs in all our environments, even in production it just has not been reported.  My beleif is it has to do with the cfsilent that surrounds the cfinclude and cfexit.  I broke up the cfsilent and it is working fine.  Perhaps the cfsilent didn't terminate correctly (???) and any display to the screen was not possible (unless the cfflush caused it).  I'm not sure but it's a puzzle.

Thanks.

[BKBK]

Cfexit? If you're not in a custom tag (and you don't seem to be), then cfabort will be more appropriate.

[Adam Cameron.]

Cfexit? If you're not in a custom tag (and you don't seem to be), then cfabort will be more appropriate.

It's fine to use <cfexit> in the way the OP describes in a non-custom tag.

The docs for <cfexit> (http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7fdd.html) are wrong.  Jamie Krug has annotated them with a correction.

--
Adam

[Adam Cameron.]

  I don't think that is our case here.  We are careful not to put cflocation's in our Application.cfm.  Since my last post, I've found out that the error occurs in all our environments, even in production it just has not been reported.  My beleif is it has to do with the cfsilent that surrounds the cfinclude and cfexit.  I broke up the cfsilent and it is working fine.  Perhaps the cfsilent didn't terminate correctly (???) and any display to the screen was not possible (unless the cfflush caused it).  I'm not sure but it's a puzzle.

I have not seen this specific behaviour, but I have seen <cfsilent> mess with stuff before in very incoherent and illogical ways.  See https://bugbase.adobe.com/index.cfm?event=bug&id=3043734 for an example of this wherein it messes with variable assignments!  Strange but true.

TBH, you've done the same sort of troubleshooting I'd suggest to do already, and having tracked it down to the <cfsilent>, I'd simply use your work around and move on.  I don't think there's going to be much to be had by investing your time getting to the bottom of it.

Can you replicate this in a very scaled down / portable fashion, eg: something you could post as a repro case for us to have a look at?  At the very least having a repro would be handy for demonstrating it to Adobe if it seems a bug needs to be raised with them.  That would probably be time well spent.

--

Adam

[CFGumby]

Adam,

  I agree and that is actually the path I have taken.  For the time being, we blamed cfsilent and moved on. 

I took a few moments and tried to duplicate the error I did it.  Below is the code.  Oddly enough the blank lines are important.  I should also note that we are still on CF7, at least for a few months more.

Thanks.

Silent1.cfm

<cfinclude template="Silent2.cfm">

<cflocation url="Silent5.cfm">

Silent2.cfm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

    <title>Untitled</title>

</head>

<body>

<cfinclude template="Silent3.cfm">

</body>

</html>

Silent3.cfm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

    <title>Untitled</title>

</head>

<body>

<cfsilent>

<cfinclude template="Silent4.cfm">

<cfexit method="EXITTEMPLATE">

</cfsilent>

</body>

</html>

Silent4.cfm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

    <title>Untitled</title>

</head>

<body>

<cfexit method="EXITTEMPLATE">

</body>

</html>

Silent5.cfm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

    <title>Untitled</title>

</head>

<body>

It worked!

</body>

</html>

[BKBK]

In my opinion, there is neither rhyme nor reason in the code you've posted. I see no motivation whatsoever for the way cfinclude, cfsilent and cfexit have been used.

When you replace each cfinclude with the respective code, you will get the following:

Silent1.cfm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

    <title>Untitled</title>

</head>

<body>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

    <title>Untitled</title>

</head>

<body>

<cfsilent>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

    <title>Untitled</title>

</head>

<body>

<cfexit method="EXITTEMPLATE">

</body>

</html>

<cfexit method="EXITTEMPLATE">

</cfsilent>

</body>

</html>

</body>

</html>

<cflocation url="Silent5.cfm">

Silent5.cfm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

    <title>Untitled</title>

</head>

<body>

It worked!

</body>

</html>

I cannot begin to understand what is going on here, let alone what you wish to achieve.

[CFGumby]

BKBK,

  this is an extremely scaled down version of our code.  I could spend a great deal of time explaining the actual code and it's function and purpose  but that is not the point.  This code was to replicate the 500 null error and it does, at least in my testing.  So please ignore the code's possible purpose and just focus on the fact that it throws a 500 null.  In the mean time we've found a solution and have moved on.

Our solution was to change this;

<cfsilent>

<cfinclude template="Silent4.cfm">

<cfexit method="EXITTEMPLATE">

</cfsilent>

to this;

<cfsilent>

<cfinclude template="Silent4.cfm">

</cfsilent>

<cfexit method="EXITTEMPLATE">

Thanks.

[BKBK]

Fair enough.