ColdFusion：遞歸太深;堆棧溢出

在過去的幾年中，我們在ColdFusion中運行計劃任務時，隨機在輸出日誌中看到此消息：ColdFusion：遞歸太深;堆棧溢出

遞歸太深;堆棧溢出。

被調用的任務內部的代碼可能會有所不同，但在這種情況下，它非常簡單，只需重置數據庫中的計數器，然後向我發送一封電子郵件，告訴我它已成功。但我已經看到它與各種代碼發生，所以我非常確定這不是導致此問題的代碼。

它甚至有一個空的application.cfm/cfc來阻止任何其他被調用的代碼。

我們唯一看到的是當我們重新啓動CF時，我們試圖在服務完全啓動之前查看頁面。

錯誤很少發生，但是現在我們有一些相當關鍵的計劃任務，如果它們不運行就會導致問題。（因此我在這裏發佈求助）

內存使用情況良好。在它報告超過80％空閒內存之前運行的任務。整夜監控內存不會顯示任何非正常的峯值。該機器有4個內存的演出，沒有其他任何運行，但操作系統和CF.我們最近試圖重新安裝CF來解決問題，但它沒有幫助。它也發生在我們的其他幾臺服務器上。

這是一個內部服務器，所以在凌晨3點使用應該不存在。當時沒有其他計劃任務正在運行。我們已經在我們的CF7，CF8和CF9盒子上看到了這個（已完全修補）。

有關信息當前框：

CF版本：9,0,1,274733

版：企業

操作系統：Windows 2003服務器

Java版本：1.6 .0_17

最小JVM堆：1024

最大JVM堆：1024

敏彼爾姆大小：64M

最大燙髮大小：384米

服務器內存：4GB

四核的機器，很少看到超過5％的CPU使用率

JVM設置：

-server -Dsun.io.useCanonCaches = false -XX：PermSize = 64m -XX：MaxPermSize = 384m -XX：+ UseParallelGC -XX：+ AggressiveHeap -Dcoldfusion.rootDir = {application.home} /../ -Dcoldfusion.libPath = {application.home} /../ lib -Doracle.jdbc。V8Compatible =真

這是令人難以置信的複雜的代碼無法運行昨晚，但已經運行了多年，並且將最有可能運行的明天：

<cfquery datasource="common_app"> 
    update import_counters 
    set current_count = 0 
</cfquery> 

<cfmail subject="Counters reset" to="[email protected]" from="[email protected]"></cfmail>

如果我錯過了什麼讓我知道。 謝謝！

來源

2010-09-03 BigWorld

你打電話的代碼是什麼？ – 2010-09-03 15:27:57

就像我上面提到的那樣，它是各種代碼（所以我對此表示懷疑），但是我編輯了我的問題並將代碼放在底部供您查看。謝謝！ – BigWorld 2010-09-03 16:04:46

這起火災的情況是什麼？它是以一天一次的時間表還是每x分鐘等等運行？ – 2010-09-03 17:03:36

我們有這個問題了，而我們的服務器升級到的ColdFusion 9.修復似乎是來自Adobe的技術在JRUN後4：http://kb2.adobe.com/cps/950/950218dc.html

你可能需要做一些調整的權限在技術說明中指出。

來源

2010-09-03 15:45:28

感謝您的評論。這也是我們最初的想法，但這意味着它永遠不會運行。由於它運行99％的時間，這不會是一個權限問題。 – BigWorld 2010-09-03 15:59:41

剛剛檢查了CF正在運行的帳戶，並按照該文章中的建議進行設置。儘管謝謝你的建議！ – BigWorld 2010-09-03 16:10:20

我不確定這是否會成爲解決所有遇到此問題的每個人的解決方案，但這是我們解決它的方法。我們擁有上文提到的丹尼文章中列出的所有權限，但是一旦我們刪除了所有權限並將其重置爲備份，我們再也沒有看到過這個問題。我們在另一臺服務器上對其進行了測試，結果發現存在問題，並在當前解決了問題。因此，即使您的設置APPEAR正確，請嘗試將其清除並重置。我不知道爲什麼它有時會被允許運行，而不是其他的......這仍然是一個謎。 – BigWorld 2010-10-29 20:13:23

您可以嘗試的是將您的CF管理員的最小JVM堆大小設置爲與您的最大JVM堆大小（MB）相同。

而且更新JVM到最新版本（21），或至少20

在過去，我一直升級JVM每當一些古怪開始發生的，通常解決了這個問題。

來源

2010-09-03 17:14:12 rip747

我認爲他已經按他的帖子做了最小/最大值 - 最小JVM堆：1024，最大JVM堆：1024.更新JVM是個好主意，但很少受到小修改的傷害。 – jfrobishow 2010-09-03 17:22:18

我會更新到最新版本並回報。這可能需要一段時間，因爲我不能強迫這個問題發生 - 它只是等待可能發生的更糟的時間，因爲它有它自己的時間表。 ;）謝謝 – BigWorld 2010-09-03 18:53:49

你有沒有試過把你的堆的大小從1024減少到800呢。你說有超過80％的內存可用，所以如果可能的話，我會考慮減少最大值。

它是32位還是64位操作系統？分配堆空間時，必須考慮JVM（堆棧，庫等）的所有開銷，以便不超出操作系統的限制。

來源

2010-09-03 17:21:15 jfrobishow

設置曾經是256/768。我們通過推薦人認爲它可以解決這個問題，將它們都提高到了1024。但它也發生在那個舊的環境中。它是一個32位操作系統，在64位內部運行，作爲虛擬機。據它可以說，它是32位。這臺機器有4個內存（不是所有的內存都可以在32位內存環境中使用），這就是爲什麼我們將它限制在1GB和384MB，並且這會爲操作系統本身留下足夠的空間。正確的，在運行時它擁有大約80％的可用內存，但它不像整天那樣 - 只是在夜晚。 – BigWorld 2010-09-03 18:56:47

如果@ rip747更新到最新jvm的建議不起作用，您可以隨時嘗試使用請求大小，因爲它們位於堆棧上。 -Xss {size} {unit}像-Xss64k。在32位Windows上默認爲320K，64k是最小的可能......所以可能會降低一點，因爲錯誤提示堆棧溢出。這是遠遠不夠的，但由於你已經有這個問題多年，它可能是值得一試。 – jfrobishow 2010-09-03 19:32:15

ColdFusion：遞歸太深;堆棧溢出

回答

相關問題