Yesodアプリケーションのデッドロックの検出のためにThreadScopeを使ってみましたが手掛かりにはなりませんでした
今日も引き続きyesod製のwebアプリケーションがクラッシュする問題を解決しようと試んでいます.
とりあえず昨日他のブランチでcssやjsのcdnからの配信に切り替えたのでそれを矛盾なくmergeする作業を行います.
gdbも試すけど, 試してなかったThreadScopeを試してみようと思います. 正直これで何かがわかるとはあまり思えないのですが…
ThreadScopeのページで書かれているRTSオプションって-Nはコア数でわかるけど,
-lsはどういう意味なんだろう.
-l[flags]
イベントをバイナリ形式でprogram.eventlogというファイルに記録する。flagsが指定されなかった場合、ThreadScopeなどのツールに適したデフォルトのイベント集合を記録する。
まさにThreadScopeみたいなソフトウェア用のオプションだったんですね…
ThreadScopeでeventlogを開いたら
There was a problem loading the eventlog.
findRunThreadTime for Event {evTime = 1030109593, evSpec = RunThread {thread = 890}, evCap = Just 0}
CallStack (from HasCallStack):
error, called at ./Events/EventDuration.hs:100:42 in main:Events.EventDuration
とかいうエラーが出てきてThreadScopeでログを見ることが出来ませんでした. 生成されたeventlogがThreadScopeで読み込める時と読み込めない時がある. さらにeventlogを生成すらしない時があります. 同じoptionを付けているのにeventlogが生成されたりされなかったりします. 意味不明.
やっとのことで見れるeventlogを生成できました.
raw eventを見てみると,
stopping thread 130(makeing foreign call)とかstopping thread 130 (heap overflow)と言った不穏な文字列が並んでいるので原因かもしれないが意味が全くわからない.
ヒープ食いつぶしているのかと思ったけど最大確保領域が68.0 MBなのでそうではないみたい.
-laを指定しないとsparkのログは見れないのか.
プロファイリングを有効にして動かしてみれば止まっている箇所の関数がわかるのではないかという思い付きが出てきたので明日試します.
今日は完全に進捗が無だった… ほかに勘による最適化(最悪手)を行ったりしたけど, 進捗はまるでありませんでした.
hatena-bookmark