CF 2018 - Random Crash When Initializing ORM Entities

[Mike-Hodgson]

Hi all,

We are seeing a really weird, totally random crash on 2018. This is with code that is currently running fine in production on 2016, and ran fine on 11. Here are definitions for three simple objects that produce the crash:

BaseEntity.cfc

component mappedSuperClass="true" accessors="true" {
    property name="id" fieldtype="id" generator="identity";
} 

BaseType.cfc

component mappedSuperClass="true" accessors="true" extends="BaseEntity" {
    property name="title" fieldtype="column" ormtype="string";
} 

PersonType.cfc 

component accessors="true" extends="BaseType" persistent="true" {
    property name="People" fieldtype="one-to-many" cfc="Person" inverse="true" inverseJoinColumn="PersonTypeID" singularname="Person";
} 

PersonType.cfc here is just an example. The third component in the chain could be totally empty (so only containing the inherited ID and Title).

What we are seeing is that Coldfusion 2018 will crash at a random time, with an exception trying to initialize a component that extends BaseType. If the page I am loading doesn't load a PersonType, but maybe loads an object of AnimalType that also extends BaseType, it could crash on that component instead. Once the crash has occurred, any code that tries to load any object that extends BaseType will crash. The only remedy is to shut down the Coldfusion service, clear the files cached in cfusion/wwwroot/WEB-INF/cfclasses, and restart the service.

When I say random, I mean that you could refresh the same page numerous times loading the same component, but at some indeterminate point it will crash with the exception.

When you drill down the exception dump to find the root cause, it always comes back to something in Coldfusion's internals:

Caused by: java.lang.ClassCastException: coldfusion.runtime.AttributeCollection cannot be cast to java.base/java.lang.String at coldfusion.runtime.TemplateProxy.findAbstractMethodsRecursively(TemplateProxy.java:1590) at coldfusion.runtime.TemplateProxy.validateAbstractContract(TemplateProxy.java:1903) at coldfusion.runtime.TemplateProxy.validateComponent(TemplateProxy.java:1541) at coldfusion.runtime.TemplateProxy.verifyInterfacesImpl(TemplateProxy.java:1952) at coldfusion.cfc.ComponentProxyFactory.getProxy(ComponentProxyFactory.java:82) at coldfusion.cfc.ComponentProxyFactory.getProxy(ComponentProxyFactory.java:56) at coldfusion.orm.hibernate.CFCTuplizer$CFCinstantiator.instantiate(CFCTuplizer.java:198) ... 125 more

It seems like this is happening when Coldfusion decides it needs to recompile/recache the component. Turning on Trusted Cache drastically reduces the chances of it happening.

Has anyone else run into this? This is a showstopper for us migrating from 2016 to 2018.

[bryan1715]

We are seeing this issue migrating from CF11 to CF2018.  This question is over a year old, is there a solution to this issue?

In our case the recursive calls to findAbstractMethodsRecursively ultimately cause a java stack overflow.

[Charlie Arehart]

FWIW, I have not heard of this error other than from this thread. To you both, I would ask if you could each confirm and report:

• what update, if any, have you applied to your CF2018? You can see that on the updates page or on the "system information" page (using the "i" in the top right corner of the CF Admin), among other places
• and can you please check to make sure that there are zero errors in the update log for whatever last CF2018 update you did apply? For more on that, see my post here. It's possible that an error in the update may be the cause, even if no other issues happen
• can you both indicate if you had done any importing of settings from another CF version, whether using the CF "archive" or CAR feature of the Admin, or by performing an import of settings on the first launch of the admin, after installation? It's possible that some unexpected setting change was brought in and is causing trouble (which would explain why the problem is seemingly rare). Here's good news: I realize you may each say you can't recall or don't know if such migration or car import was done. But fortunately there is a log that CF keeps, if either is ever done. See the CF logs folder, and is there a log whose name starts with migration or car? If so, read the log to see what sort of things happened, and if any error happened.

Hope that may help. If not, perhaps others will chime in.

[Mike-Hodgson]

Hi Charlie,

Two years later, trying again with a brand new server with CF2018 completely up-to-date, same crash occurs. I am doing some more testing today to verify that our crash is also due to the recursive findAbstractMethodsRecursively calls the other commenters have mentioned.

[Charlie Arehart]

Mike, have you gotten anywhere with this problem since last week? 

[defaulttki1rx9p5dco]

Was there ever a solution to this?  We're having the same issue with findAbstractMethodsRecursively causing a stack overflow while migrating from CF11 to CF2021

[Mike-Hodgson]

We have not found a solution yet. We have been continuing to stay on 2016, but with it reaching EOL we are trying to migrate again. Fresh install of CF2018 on a new server, all of the latest updates applied, same random crash 😞

We're going to give it a try with CF2021, and see if the issue still persists there.

[BKBK]

A guess.

Given the setting, accessors="true", ColdFusion will create, under the hood, getter and setter functions for each of the properties. However, to be able to do so properly, ColdFusion must know the type or data-type of each property. If it doesn't it will try to make an intelligent guess.

One such guess was AttributeCollection, whereas the correct type expected was String. Hence the exception that @Mike-Hodgson reports.

If my guess is correct, then a possible solution will be to specify the type and, where applicable, ormType or elementType of each property.

[Charlie Arehart]

And if bkbk's reasonable suggestion doesn't pan out (for all 3 raising this issue here), the next question would be to conform if the other two are indeed using orm, like Mike raised initially. Despite it being in the title, they may be here simply for the error msg.

And have the other two tried using trusted cache like Mike proposed at the end of his first post? Besides possibly tempering the problem, if it helped it could be another useful diagnostic.

And have you all tried the latest cf update (u11 for 2018 and u1 for 2021). Just trying to bound any similarities or differences. Finally, have any of you tried the next update for each, which have been in prerelease for a few months (for unrelated reasons)? More at prerelease.adobe.com, or a blog post in did (https://www.carehart.org/blog/client/index.cfm/2021/7/19/dont_miss_prerelease_updates_to_CF2021_and_...). It could be that the update helps.

If not, and nothing anyone poses here does, then it would seem time for one of you to open a bug report (at tracker.adobe.com), pointing it to this thread and posting the ticket number here.  But before doing that, please do consider first what bkbk offered, then mine here. 

[Charlie Arehart]

defaulttki1rx9p5dco, any update? 

[BKBK]

@Mike-Hodgson ,

Have you given it a try on CF2021?

If the issue persists, will you try my suggestion?

[Mike-Hodgson]

Yes, it does persist on 2021 with the latest updates.

We're currently testing with the type attribute added in places it wasn't previously.

[Nathan_Paul]

I work with Mike, and have recently been attempting to resolve this bug. I tried adding a type to every one of component properties, and it came with no succes to resolving the issue.

We did catch our eye on this: https://tracker.adobe.com/#/view/CF-4203425 Our issue seems to be this, except rather than occuring after serializeJSON, it occurs after an undetermined event. We even have a mappedsuperclass with the name "name". I will attempt to move the property to the child classes to see if this solves the issue.

[BKBK]

Thanks for the update, @Nathan_Paul . If I were you I would change the name from "name" to something like "propName". If that resolves the issue, will you please request Adobe to reopen the ticket  https://tracker.adobe.com/#/view/CF-4203425 

[Nathan_Paul]

Unfortunately, changing the name of "name" would be far to large a task for us, there are thousands of references. 

However, I did remove"name" from our mappedSuperClass. And added it onto each child class, and this seems to have resolved the issue. 

[bryan1715]

If it may help others, as there still seems to be an issue with this in current version of CF (2021).  We were able to resolve the issue by removeing function arguments named "abstract".  One instance was in a library we used (ColdSpring) that we had to modify by changing the function argument name and all references to it in the library function.  Another was a DB field named "abstract" that we renamed so we could keep references to it in our code consistent with the field name.  Making these changes allowed us to move to CF2018 and did not present an issue with moving forward to CF2021 either.