2011-10-05 111 views
23

我有可能會導致下面的輸出死服務器:調試「最大調用堆棧大小超出」

events.js:38 
EventEmitter.prototype.emit = function(type) { 
           ^
RangeError: Maximum call stack size exceeded 

然而,沒有一個堆棧轉儲或跟蹤,我沒有發現這是否方式是無限遞歸或僅僅是一個稍大的鏈,更不用說問題函數的位置了。

--trace選項來運行節點引起我的測試,不僅運行緩慢(如人們所期望的),但不重現該問題。

任何人有任何解決方案或技巧來達到這個底部?

+0

這個具體問題是由前後對比的diff解決後,這是衆所周知的發生,堅持通過每次新/更改的'emit'調用進行額外的日誌記錄,並發現導致「drain」事件發生聯合遞歸的範圍錯誤 - 因此速度敏感。 我仍然會將已接受的答案授予最佳一般策略,這也將解決此問題。 – OrangeDog

回答

9

看來答案是當前:穩坐,等待Node.js的更新到新的V8版,或the patch from this Chromium project bug report建立你自己的。

This archived thread from the v8-dev mailing list表示在

  • 戴夫·史密斯帶來了這個非常問題,並提出了一個補丁
  • 的Chromium項目的楊過討論它的討論,文件對這一問題的鉻錯誤,並應用不同的修補程序
  • Dave注意到Node(當時的0.8)使用V8 3.11並詢問backporting補丁。楊回覆說,這個補丁可能會在V8 3.15上着陸,並且不會被回溯。

注意導入Node.js使用的V8 3.11 V0.8; Node.js 0.10目前使用V8 3.14。因此,就Node而言,Chromium接受的補丁仍然是「未來的」補丁。

(這個答案欠拜@Coderoshi,因爲它是按照從他的回答,我學會了這一切的線索。)

+0

有關這方面的任何消息嗎?我遇到同樣的問題,我必須調試「RangeError:超出最大調用堆棧大小」。問題在於它幾天後發生在一個未改變的web應用程序中,我不知道如何搜索,因此stacktrace會有很大的幫助。 –

+0

在這種情況下,節點0.11正在使用足夠新的V8版本來顯示堆棧跟蹤。如果你能夠在節點0.11下運行你的webapp,那就試試吧。 – metamatt

+1

剛剛嘗試v.0.11.6,雖然我能夠運行webapp,但堆棧跟蹤無效。無論如何,我修復了這個錯誤,但是我認爲這個評論對於那些有類似錯誤的人來說可能對搜索堆棧跟蹤很有用。也許它節省了一些時間,而不是編譯不穩定的版本;-)。 –

4

它是一個「稍大的鏈」似乎不太可能。

它可能是一個調用觸發自身的事件的函數。

所以,如果代碼放慢使無限遞歸停止。 我的猜測是你有一個隊列和較慢的模式,它沒有得到儘快填充 。

如果這沒有幫助,那麼我認爲我需要更多的信息。 也許有人對此有一個全面的瞭解。

2

此修補程序可能會幫助您找到解決方案。這極大地擴展堆棧跟蹤:

https://github.com/dizzyd/node/commit/40434019540ffc17e984ff0653500a3c5db87deb

+0

這似乎是正確的做法。我不會將此補丁描述爲「極大地擴展堆棧跟蹤」;我將其描述爲「嘗試構建棧溢出異常的堆棧跟蹤更難」。順便說一句,這個補丁修改的代碼包含對TODO(1240995)的引用;任何人都知道是指什麼錯誤數據庫? – metamatt

+0

我沒有發現任何bug 1240995,但我確實發現了dizzyd的補丁變成了什麼;請參閱http://stackoverflow.com/a/15664576/275581。 – metamatt

相關問題