問題タブ [stack-dump]

Linux上のCでプログラムのシグナルを処理するために代替スタックを使用しています。スタックオーバーフローが発生すると、信号はメインスタックではなく代替信号スタックに配信されます。

したがって、この状況では、メインスタックをダンプしたいのですが...どうすればよいですか？

Eclipse メモリ アナライザーは、「無効なHPROFファイル ヘッダー」というメッセージのみを表示します。

スタック ダンプ:

HPROF ファイルは Linux マシンで作成されました。

HATは機能せず、IBM HeapAnalyzerは複雑すぎますが、機能しました。

機能させるにはどうすればよいですか？

gcc 4.4.3 c89

私は次のソースコードを持っています。そして、printfでスタックダンプを取得します。

このようなchar配列を作成する必要があると思います。

そして、各要素に文字列を格納できます。

提案をありがとう、

==修正を追加===

デフォルトでは、Hotspot を使用すると、CTRL-Break スレッド ダンプはjava.lang.concurrentロックを保持しているスレッドを一覧表示しません。また、これらのロックでは、ロックが取得されたスタック フレームに関する情報を Hotspot が取得できないことを理解しています。JVM オプションを追加すると-XX:+PrintConcurrentLocks、CTRL-Break スタック ダンプが (スレッドのスタック トレースの後に) そのフレームによって保持されている同時ロックを一覧表示します。例えば：

このオプションがないと、事後分析でこのロックを保持しているスレッドを特定することはできません。このオプションがデフォルトでないのはなぜですか? 明白でないパフォーマンスまたは安定性のペナルティはありますか? これについての議論を探すために検索しても、何も出てきません。

アプリケーション [rtorrent] がクラッシュした後core、250MB のファイルが生成されました。

私が必要としているのは、スタック トレースを分析して確認し、rtorrent が頻繁にクラッシュする理由を知ることです。

いくつかの外部ツールを使用してテストを実施する自動テスト システムを実行しています。それらの 1 つがクラッシュした場合 (ツール自体は私がテストしているものではありませんが)、foo.exe.stackdump作成されたファイルを保存したいと思います。ただし、このファイルがどこに作成されているかについて明確な答えを見つけることができませんでした。私の仮定は、それが作業ディレクトリにあるということでした（ただし、ディレクトリはテスト間で自動的にパージされるため、確認できません）。オンラインで明確な答えを見つけることができませんでした. Windows 7 で Cygwin 1.7.7 を使用しています。

かなり奇妙な問題が手元にあります。Linux 2.6.35-14 で kdump/kexec をセットアップしようとしています。

すべて正常に動作し、「echo c > /proc/sysrq-trigger」でクラッシュを引き起こしています。

ただし、クラッシュを呼び出すたびにコア ファイルのサイズが 2 倍になることがわかりました。:s:s

• 最初のクラッシュ: 347Mb
• 2 回目のクラッシュ: 622Mb
• 3 回目のクラッシュ: 1.2Gb
• 4 回目のクラッシュ: 2.2Gb

なぜこれができるのかについて、人々は何らかの洞察を持っていますか? したがって、解決策は何でしょうか？

どうもありがとう。

この質問は、Cygwin 実行可能ファイルからのスタックダンプの使用の繰り返しである可能性がありますが、私は初心者であり、回答や質問の一部さえ理解していませんでした。

私は C++ とプログラミングの初心者であり、NetBeans で開発しています。私は問題なくコンパイルできるが、実行中に失敗するいくつかのコードに取り組んでいます。デバッガーを使用すると、次のエラーが発生します。

ファイル all.exe.stackdump を見つけることができました。メモ帳 ++ を介して読み取ることができますが、その意味がわかりません。このファイルをデコードするユーザーフレンドリーな方法があるという別の質問を集めましたが、私の最善の推測bash$ gdb all.exe.stackdumpでは効果がありませんでした。このファイルをデバッグに使用する最良の方法は何ですか?

参考までに、all.exe.stackdump の内容を以下に示します。

Ubuntu12.10でi686-w64-mingw32-gcc4.7.2クロスコンパイラを使用してwin32アプリケーションを開発します。

リリースモードでコンパイルされたアプリケーションを実行してクラッシュすると、次のような出力が表示される場合があります。

私はそれをどのように解釈するのか疑問に思っていますか？それから得られる有用な情報はありますか？たとえば、スタックダンプからソースコードの行を取得することは可能でしょうか？

try/catch以下のコードでは、python モジュールコードで使用しています。ブロックにtry単純なエラー (メモリ アクセス違反) があり、対応する例外をキャッチして、.stackdumpファイルを生成せずにプログラムを静かに終了しようとしています。ただし、後者はまだ生成されており、try/catchコンストラクトがその仕事をしていないことを意味します。不適切な操作 (コード内の操作など) が発生した場合に、ファイルの生成を回避.stackdumpし、エラーなしでプログラムを終了するにはどうすればよいですか? PS私はgccとboost.pythonを使ってcygwinでコードをコンパイルしています

x[3]=2の場合にのみ機能するのではなく、他のすべての場合に機能x[4]=2するのは興味深いことx[20]=2ですx[2]=2。

編集：

Maciek が提案したことによると、次のトリックを試しました。

例外をスローするシグナル処理関数を作成しますが、終了しません

次に、問題のある可能性のある関数を try/catch ブロックで囲みます (シグナル関数はクラス コンストラクターに配置されます)。

ただし、このようなトリックは期待どおりに機能せず、次の出力が生成されます。

したがって、例外がスローされますが、キャッチされる前にすべてが終了します。プロセスを終了する前にキャッチする方法はありますか?