Open mhoyer opened 10 years ago
ThreadAbortException
). It appears very rarly and some hours after deployment to our servers. So the cached local files were not touched for longer period.StackOverflowException
by simply putting a breakpoint to this line in ExceptionCatchingBundleCollectionInitializer
and setting a WhenHit
statement to {throw new System.NotSupportedException()}
I, too, am having this problem. It is extremely sporadic, and I haven't been able to figure out how to consistently reproduce it at will. But when it DOES happen, it continues to happen consistently for a while thereafter (that is, it's not just a random one-off thing every so often -- once it occurs, it continues occuring). I usually try things like: deleting the Cassette cache, rebuilding my project, modifying the web.config settings... and at some point it will start working again. But I can't find one particular thing that seems to fix the problem.
One thing that seems to instigate this issue more regularly is modifying or adding files to the file system. For example, I'm working with ReactJS and have a weather component. I dropped in a "weather-icons" directory where my script is, which contains some CSS and font files. And that caused cassette to blow up with this StackOverflowException. I've also experienced it after just modifying some of the javascript files themselves.
I'll continue to investigate but if anyone has any ideas -- or something more specific -- I'm happy to test or provide more feedback.
Some details about my setup:
Perhaps related perhaps not, but I was just experiencing an issue I traced down to Cassette which has similar symptoms--except it was EVERY request that used Cassete was causing a stack overflow and crashing my w3wp process. The cause was I was missing JS files when my project built in Azure, so references (I assume) were missing and Cassette was having some trouble. The symptom I saw was 502 Bad Gateway errors on every request that included a reference to a Cassette bundle. My MVC actions that didn't return a full view worked fine and once I discovered the cause (missing JS files), adding them back fixed it.
Now that I know what causes it, I could probably try reproducing it locally to see what Cassette is doing.
We recently found weird behavior related to Cassette in our web application for a quite large customer. Sometimes a HTTP requests from a users browser took minutes to respond on our live environment. We sadly couldn't reproduce it on our internal environments so the only way to find out about the actual reason was by dumping the w3p.exe process of live IIS and inspecting it with WinDbg. So fasten your seatbelt and see what we did:
Requirements
I used
Procedure
Open WinDbg and with File > Load Crash Dump I loaded the dump.
Preparing the session
Find the threads with locks
Okay. DbgThread 140 looks interesting. So I switched to it with:
Now list the full stack trace of this thread:
Scrolling through the very long list of calls in the stack I found a lot (more than 100 times) of loops over those 8 lines:
Thus, I inspected all involved types of those lines:
Cassette.Bundle
Cassette.BundleCollection
Cassette.CacheAwareBundleCollectionInitializer
Cassette.CachedBundleContent
Cassette.Caching.ManifestValidator
Cassette.Caching.ResourceAssetCacheValidator
Cassette.ExceptionCatchingBundleCollectionInitializer
After digging into source code of Cassette for those particular types I found
BundleCollection.GetReadLock()
andExceptionCatchingBundleCollectionInitializer
quite interesting regarding the stateful propertyBundleCollection.InitializationException
.Now I ran the
!mdso
command for this particular type holding the BundleCollection.InitializationException and click the Object address link in the output:This link (000000f240dbb340) automatically executed this command:
See the
initializationException
field inside the output? It's of typeThreadAbortException
!My guess is the IIS app pool was recycled, kicked, thread-aborted, whatever and now the looping starts. Especially in conjunction with the implementation of
ExceptionCatchingBundleCollectionInitializer
: I am wondering why there is no more concrete exception type matching in the try-catch block of itsInitialize
method?