tracker issue : CF-4161484

select a category, or use search below
(searches all categories and all time range)
Title:

Stack traces inconsistent with previous CF releases

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/AsDesigned

Reporter/Name(from Bugbase): Tim Parker / Tim Parker (Tim Parker)

Created: 06/06/2016

Components: Debugging

Versions: 2016

Failure Type:

Found In Build/Fixed In Build: CF2016_Final /

Priority/Frequency: Major / All users will encounter

Locale/System: ALL / Linux All

Vote Count: 0

Problem Description: Stack traces report inconsistent paths for modules in the same directory - module called directly by web server shows symlink (un-translated), other modules (called by the originally-requested module) use the target of the symlink.  This inconsistent handling of symlinks is seen both at the Java level (stack trace available via exception object) and in a dumped CF exception (these steps use a simple exception to demonstrate the problem)

For our application, this is critical, since we're inspecting the call stack to ensure that a module is called only from an approved location (example: ensure that 'build-a-datasource.cfm' is only called from '.../installation/setup.cfm' and not from any arbitrary location)

Steps to Reproduce:

Create a directory 'A' at the web root
Create a symbolic link 'B', also at the web root, which points to a (ln -s A B)

Create two modules in this directory:

dump-stack.cfm:
<cfset a=b> <!--- this will throw an exception, including the stack trace if 'Enable Robust Exception Information' is checked in CF Admin's 'Debug Output Settings' -->

call-dump-stack.cfm
<cfmodule template="dump-stack.cfm">

Browse to {server}/A/call-dump-stack.cfm - stack is correct (shows .../A/ as directory for both modules)
Browse to {server}/B/call-dump-stack.cfm - stack is incorrect (shows .../B/ as directory for call-dump-stack.cfm, and .../A/ as directory for dump-stack.cfm

This behavior is inconsistent with previous CF releases (tested with 9, 10, and 11) [the translated path is used for all stack entries, including the original called module]

Actual Result:

Expected Result:

Any Workarounds:
Don't use symbolic links if the actual path matters in your logic (or don't upgrade to CF2016)

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	4161484

External Customer Info:
External Company:  
External Customer Name: Tim Parker
External Customer Email:  
External Test Config: My Hardware and Environment details: Centos 7 (Linux) VM w/JDK 8 (92), 4GB memory

Attachments:

Comments:

encountered with CF2016 Update 1 (option not available in Found in Build drop-down) Platform is Linux - Centos 7 (option not available in Platform drop-down) Browser doesn't matter in this case, but Browser drop-down is also missing many current values
Comment by External U.
2493 | June 06, 2016 06:41:30 PM GMT
This is as part of the bug # CF-4024546. Please visit https://forums.adobe.com/message/194862#194862. Please don't use symbolic link instead use actual path.
Comment by Poonam J.
2494 | June 27, 2016 01:44:32 AM GMT
The "please don't use symbolic link..." part of this response is completely unacceptable - Symbolic links are a critical part of a system administrator's collection of tools. The forum article referred to is just one of many examples of why symbolic links are useful. The user who posted that forum article was also right that symbolic links shouldn't be translated, but that's something that can be worked around - but only if CF is *consistent*. Previous versions of ColdFusion (7/8/9/10) are consistent, where 2016 is not.
Comment by External U.
2495 | June 27, 2016 10:20:53 AM GMT
The reported bug is that paths in stack traces are inconsistent. This is a bug, I am not withdrawing it, and if this is really 'as designed'... we're all in trouble.
Comment by External U.
2496 | June 27, 2016 10:34:48 AM GMT
I agree 100% with Tim. This is an important and undeniable inconsistency, and a significant change of behavior vs all previous releases. It should have been escalated to a higher level of decision making before simply implementing it based on a 10 year old complaint about CF 7, and that's what should happen now, as soon as possible. As for "please don't use symbolic link...", what? Administrators use simlinks for many reasons, and ColdFusion as a platform shouldn't think it can dictate that kind of policy for everyone everywhere. Are you saying that for this reason alone some sites can't use CF 2016? Is that really what you want for an outcome?
Comment by External U.
2497 | June 27, 2016 10:53:59 AM GMT