問題タブ [panic]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
678 参照

linux-kernel - 起動時のUbuntu OpenVZカーネルパニックエラー

Ubuntu 14.04 Trusty プラットフォームで OpenVZ を使用したいと考えています。Ubuntu 13.04 での OpenVZのインストールと使用 (AMD64) の指示に従って、RHEL6 2.6.32 カーネル (vzkernel_2.6.32-042stab093.5_amd64 カーネル) を インストールしました。

vzkernel_2.6.32 でマシンを起動すると、次のエラーが表示されます。

"カーネル パニック - 同期していません: 致命的な例外"

そしてブートがフリーズします。ただし、起動を中断して元の Ubuntu カーネルを選択すると、マシンは正常に起動します。

添付のスクリーンショットをご覧ください。 カーネル パニック ブート エラーのスクリーン ショット

ブートメニュー: imgur.com/5VjBZUj

ハードウェア: Dell PowerEdge T105 (クアッドコア CPU、8 GB RAM)

OS: Ubuntu 14:04 (トラスティ) 64 ビット

uname -r: 3.13.0-39-generic

OpenVZ 用に次のコンポーネントをインストールしました。

ploop-1.12.1-1.x86_64.rpm
vzctl-core-4.8-1.x86_64.rpm ploop-lib-1.12.1-1.x86_64.rpm
vzkernel-2.6.32-042stab093.5.x86_64.rpm vzctl- 4.8-1.x86_64.rpm
vzquota-3.1-1.x86_64.rpm

インストールには次の手順を使用しました。

これを修正するための助けがあれば大歓迎です。

ありがとう

0 投票する
0 に答える
949 参照

android - Android でのカーネル パニックのバックトレースの分析 / 原因の特定

Samsung Galaxy Note 2 LTEでこの問題が発生し、カーネルログでランダムな再起動と一種のクリーンな再起動が発生し(USBエラーが発生しても、おっと/パニックは発生しません)、la​​st_kmsgログでカーネルパニックが発生しました。このログでは、モデムを起動しようとした 10 回の試行を認識しましたが、すべて失敗し、その後、再起動がタイムアウトしたためにカーネルがパニックに陥りました。

5.5 秒間隔のモデム起動シーケンスの繰り返し:

カーネル パニックと最後の試行:

その後、ブートローダーが起動します。

これが完全なlast_kmsgログです。

どうすればメモリ ダンプを取得できますか (デスクトップ Linux カーネルのデバッグについて読んで理解した限りでは必要です)、パニックの正確な原因を分析するにはどうすればよいですcrashbt?
または、これがハードウェアの問題なのか、それとも現在のログだけからどのソフトウェア部分が間違っているのかを調べるために、別のことをする必要がありますか?

どんな助けでも大歓迎です!

ファイトクッキー

0 投票する
1 に答える
97 参照

json - 成功した型アサーションをテストする手段として panic/recover を使用しても問題ありませんか?

私は、情報を定義済みの構造体にマッピングせずに、ネストされた JSON 応答を解析しようとする方法に取り組んできました。

空白のインターフェイスでは、次のように返されます。

だから私はこの情報をナビゲートするために以下を使用しています:

これは、JSON 文字列から情報を解析するための受け入れ可能な方法ですか、それともより好ましい方法がありますか?

上記を使用して、現在使用している正しい情報を解析する例を次に示します。

どんな洞察もいただければ幸いです!ありがとう!

0 投票する
3 に答える
587 参照

recursion - Go の再帰関数で、内側の関数が戻った場合、外側の関数は正常に実行を継続しますか?

さて、私はこのコードを持っています

説明:

何かが正しくない場合に関数が再試行する回数を表す引数 n (5 としましょう) を指定して関数を呼び出します。何か問題が発生するたびに、n-1 で再帰呼び出しを行うため、n=1 に達するとあきらめて false を返します。このコードは実際には問題なく動作し、本来の動作を行います。応答が正しくない場合は、再帰的に自分自身を呼び出し、2 回目 (または 3 回目、4 回目..) に動作します。n=1 になる前に問題が修正されない場合は、false を返します。

問題:

これは、約 17 時間実行されるはずの大きなコードの一部であり、次の行で本文から読み取ろうとするとパニックになります。

パニック: ランタイム エラー: 無効なメモリ アドレスまたは nil ポインター逆参照と表示されます。これはおそらく、存在しない resp.Body から読み取ろうとしていることを意味していることがわかりましたが、Go のドキュメントには、 err が nil の場合、 resp には常に nil 以外の resp.Body が含まれていると明確に記載されています。

だから、私の頭の中では、おそらく再帰呼び出しを伴うものです。私にとって理にかなっている唯一のことは、このシナリオです: エラーが nil ではない (これは resp.Body が存在しないことを意味します) としましょう。 1 の場合、n=4 で再び自分自身を呼び出します。今回はすべてが正常で、2 番目の関数が最初の関数に true を返しますが、最初の関数は実行を続行し、存在しない resp.Body から読み取ろうとするとしますそれはパニックを引き起こし、ここにいます...

だから、私が必要としているのは、再帰関数がどのように機能するかを正確に知っている人です。

とにかく、ありがとう!:)

更新:大丈夫でした。私のコードはもうパニックにならず、私もそうではありません。どうもありがとうございました! (ここがアップデートの対象かどうかはわかりません)

0 投票する
2 に答える
5044 参照

linux - CentOs 7 がクラッシュ カーネルの起動に失敗し、/var/crash にダンプを生成する

CentOS 7 サーバーがカーネル パニック時に /var/crash にカーネル ダンプ ファイルを生成しないという問題があります。クラッシュ カーネルが起動しないようです。Rhel ガイド ( http://red.ht/1sCztdv ) に従ってクラッシュ ダンプを構成しましたが、一見するとすべてが正しく構成されているように見えます。次のようなパニックを引き起こしています。

これにより、システムがフリーズします。コンソールにメッセージが表示されず、コンソールが応答しなくなります。この時点で、システムがクラッシュ カーネルを起動し、/var/crash へのダンプの書き込みを開始すると想像できます。ダンプ全体を完了する時間を与えるために、この凍結状態で最大 30 分間放置しました。ただし、ハード コールド リブート後 /var/crash は空です。

さらに、期待どおりに KVM 仮想マシンと kdump ワードで構成を複製しました。したがって、物理システムの構成に何か問題があるか、ダンプではなくハングを引き起こすハードウェア構成に何か奇妙なことがあります。

私たちのサーバーは、24 コアと 128 GB のメモリを搭載した HP G9 です。その他の詳細は次のとおりです。






0 投票する
1 に答える
1057 参照

c - alloc: 無効なブロック - Tcl_IncrRefCount と Tcl_DecrRefCount は、スレッド化された Tcl / スレッドあたり 1 interp に対してスレッドセーフですか?

当社の 32 ビット サーバー アプリケーションには、tcl 8.4.11 が静的に組み込まれています。Red Hat Linux 6.5 64 ビットでは、クラッシュやコア ダンプが発生します。失敗は次のようになります

alloc: 無効なブロック: 0xf6f00f58: 88 f6 0

質問の最後に、私たちが確認した 2 つの異なるコア ダンプを記載しました。

別々の TCL インタープリター インスタンスを同時に実行している 2 つのスレッド間で共有される TCL オブジェクトに、潜在的な根本原因を切り分けました。これは、これらの同時実行 TCL インタープリターから Tcl_IncrRefCount / Tcl_DecrRefCount に TCL オブジェクトが渡されるためだと考えられます。

  1. TCL がスレッド化されてコンパイルされている場合、Tcl_IncrRefCount / Tcl_DecrRefCount はスレッドセーフですか?
  2. TCL オブジェクトは TCL インタープリター インスタンスによって共有されますか? インタプリタ インスタンス間での TCL オブジェクトの共有を無効にする方法はありますか?
  3. TCL バージョン 8.6.3 では状況は改善されていますか?