tracker issue : CF-4165797

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

reReplaceNoCase is throwing a java.lang.StackOverflowError at org.apache.oro.text.regex.Perl5Matcher when using Java 1.8

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/AsDesigned

Reporter/Name(from Bugbase): Darrell Rapier / Darrell Rapier (Darrell Rapier)

Created: 06/18/2016

Components: Core Runtime

Versions: 11.0

Failure Type: Unspecified

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Normal / All users will encounter

Locale/System: English / Win 2012 Server x64

Vote Count: 1

Problem Description:

The regular expression in reReplaceNoCase is throwing an error when it should be matching the string with the regex and then replacing the matched string. This same code worked fine with Java 1.7.0_72.

Steps to Reproduce:

<cfsavecontent variable="variables.largeTextString">
test1 test2
<!--[CODE]-->
test to remove this inner text...
enter lots of text here
<!--[/CODE]-->
test3 test4
</cfsavecontent>
<cfset variables.newString = reReplaceNoCase(variables.largeTextString,"(<!--\[CODE\]-->)(.|\n)*?(<!--\[/CODE\]-->)","","all")>

Actual Result:

Throws this stack trace error...
java.lang.StackOverflowError at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at...
This dump goes on for several pages.

Expected Result:

All text in the regex expression should be replaced with an empty string.  The output from variables.newString should be "test1 test2 test3 test4".

Any Workarounds:

This used to work with Java 1.7 then broke when we upgraded Java to 1.8.0_92

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

Watson Bug ID:	4165797

External Customer Info:
External Company:  
External Customer Name: Darrell Rapier
External Customer Email:  
External Test Config: Windows Server 2012 /w IIS 8.5

CF11 Update 9 running Java 1.8.0_92

Attachments:

Comments:

Hi Darrell, I have tried to repro this issue with the given code snippet. But I am unable to repro this. I am getting the expected output. Have you tried applying the latest hotfix of ColdFusion 11? -Nimit
Comment by Nimit S.
2345 | June 20, 2016 01:22:46 AM GMT
Yes, I have applied the latest hotfix. I indicated that there has to be a lot of text to replace for this to kick an internal error. Try this code instead. You will see this is an internal Java issue and it does not run the cfcatch so you will have to look at the coldfusion-error.log for more details. I verified this issue on 3 of my CF11 servers. <cftry> <cfsavecontent variable="variables.largeTextString"> test1 test2 test3 <!--[CODE]--> a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... a lot more text... <!--[/CODE]--> test4 test4 test5 </cfsavecontent> <cfset variables.newString = reReplaceNoCase(variables.largeTextString,"(<!--\[CODE\]-->)(.|\n)*?(<!--\[/CODE\]-->)","","all")> <cfdump var="#variables.newString#"> <cfcatch type="any"> <cfdump var="#cfcatch#"> </cfcatch> </cftry> You should see something like this in the log file. Jun 21, 2016 7:25:20 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [CfmServlet] in context with path [] threw exception [Servlet execution threw an exception] with root cause java.lang.StackOverflowError at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) at org.apache.oro.text.regex.Perl5.....
Comment by External U.
2346 | June 21, 2016 06:00:17 AM GMT
Thanks Darrell for providing this information. I am getting this exception in the command prompt. Are you getting this exception in the browser as well? -Nimit
Comment by Nimit S.
2347 | June 21, 2016 06:33:44 AM GMT
Here's a possible Java solution that avoids using Adobe's built-in blackbox function. This should perform faster without throwing any errors: <cfset variables.newString = variables.newString.ReplaceAll("(?ims)(<!--\[CODE\]-->).*(<!--\[/CODE\]-->)", "")> i = insensitive. Case insensitive match (ignores case of [a-zA-Z]) m = multi-line. Causes ^ and $ to match the begin/end of each line (not only begin/end of string) s = single line. Dot matches newline characters
Comment by External U.
2348 | June 23, 2016 10:07:34 AM GMT
It may also be due to the regex capture group you are using... not sure. I tested "(<!--\[CODE\]-->).*(<!--\[/CODE\]-->)"" with reReplaceNoCase() and it seemed to replace the string without any error. I'm not sure why the original regex works with shorter strings and would fail with larger ones. (I know that java's ReplaceAll doesn't use matcher... so it could be a matcher issue with the regex pattern.)
Comment by External U.
2349 | June 23, 2016 10:13:31 AM GMT
Yes. I receive this exception in the browser as well. I did confirm that James' Java solution does work. The reReplaceNoCase() only works when the regex matches less than 1587 characters. Anything more leads to this exception.
Comment by External U.
2350 | June 28, 2016 06:02:20 AM GMT
For the record, I tested the initial ReReplaceNoCase() sample using CFTry.com and it works with CF9 & 10 and Railo5... but not CF2016 (2016,0,01,298513).
Comment by External U.
2351 | June 28, 2016 08:09:12 AM GMT
reReplaceNoCase method internally makes recursive calls on your regex, the bigger your text is bigger stack(for recursive calls) it will create. Java sets some default value on maximum size of the stack which you can increase in jvm.config file using this "-Xss" property. While using regex if your text is so huge that the recursive call stack exceeded this value then you will face this java.lang.StackOverflowError. This error existed in CF10, 11 also but probably you are not facing it because of the difference in jvm version or the difference in -Xss property. To fix this in CF2016 please increase the value of this property in jvm.config or improve your regex pattern. To reproduce this is earlier versions of CF please try reducing this property value in jvm.config I tried in trycf.com also but it is not throwing error now with your given example but if you increase the text it throws and similarly it throws for larger text in older versions of CF too. closing this bug as "AsDesigned".
Comment by Milan C.
2352 | July 18, 2016 05:43:34 AM GMT
While reviewing this page after encountering a CF2016 error, I realized that my comments have had my name removed from them and replaced with "External U". I'm not sure why this happened. I'm placing another comment to determine if my name (James) is retained.
Comment by James M.
30238 | February 12, 2019 09:39:53 PM GMT
FWIW, the code offered on 6/21/16 above DOES work in CF2016, at least per the latest update (11) as run on cffiddle.org. Curiously, it does FAIL (with an unhandled exception) on CF2018 update 4 (also latest, at this writing), when run on cffiddle.org. It's curious to wonder what would a) make it work in 2016 now when it did not for others here in the past, and then b) why it would now fail in 2018. And James, that "external user" issue was not unique to you. I believe it happened when Adobe moved to the new tracker (from the old bugbase) and they could not for some reason keep the names of external users. Note that the names of Adobe folks (like Nimit here) WERE preserved in that move.
Comment by Charlie A.
30917 | June 13, 2019 08:54:29 PM GMT