第674回 カーネルのクラッシュ情報を解析する | gihyo.jp
第673回の「カーネルのクラッシュ情報を取得する」では、カーネルクラッシュ時に情報を収集する仕組みを有効化しました。得られた情報は活用しないと意味がありません。今回はその中身を解析する方法を紹介します。 デバッグパッケージのインストール 第673回では、意図的にシステムをクラッシュさせることで、dmesgとvmcoreを取得しました。カーネルが今際の際に次につながる情報を残してくれたのです。「しかしながらあのクラッシュが最後のpanicだとは思えない。もし、同じカーネルが続けて使われるとしたら、あのpanicの同類が、また世界のどこかへ現れてくるかもしれない……」 最初に行うべきなのは、前回紹介したように問題発生時のdmesgを読むことです。これである程度、状況の絞り込みは行えますし、運が良ければ原因がわかることもあります。しかしながら、dmesgだけだと「問題が起きた場所」はわかっても
システムコールトレーシング: 吸い込まれる標準入力を観察する - にゃみかんてっくろぐ
Linuxその2 Advent Calendar 2020 18 日目の記事です。 「スクリプト書いてたんですが、なぜか途中で止まるんです」と言われた。 止まっている様子（シンタックスハイライトが綺麗でないので画像で） 確かに yarn gen で止まっている。 yarn start も date も実行されていない。終了コードは 0 で、正常だ。 「ファイルとして実行してみて」と伝えた。 最後まで実行される様子 最後まで実行された。 雰囲気で「たぶん 標準入力が吸い込まれている」と雑返答をしてしまったが、ここでその正体を明らかにしておきたい。 1. strace でシステムコールを記録する 2. システムコールから挙動を観察する 2-1. ヒアドキュメントの書き出し 2-2. 標準入力をヒアドキュメントに差し替え 2-3. bash を実行 2-4. 標準入力を読み込み 2-5. dat
Linuxカーネルの起動時トレースの話 - Qiita
カーネル起動時トレース Linuxカーネルの起動処理は、様々なことが行われるのにそれをデバッグする方法はprintkだったり、逆にkgdbを外部デバッガから繋いだりと、結構な手間がかかっていました。カーネルが起動してしまえば、ftraceにperf, BPF, systemtapと複数の手段が使えるのに、起動時のデバッグは細かいことが出来ません。これは、起動時に指定できるオプションが大雑把になるのが大きな理由の一つでした。シェル芸ではないですが、1行プログラミングだけで様々なことをするのは大変です。 そこで導入されたのがExtra Boot Configuration (bootconfig)です。Bootconfigについては前回の記事を参考にしてください。 ここではカーネルコマンドラインのトレースオプションと、Bootconfigによって拡張されたBoot-time trace（CON
ChromeのデベロッパーツールでJSをデバッグする方法(2022年版) - ICS MEDIA
JavaScriptのデバッグは、ウェブ開発の必須スキルのひとつです。プログラムの実行をデバッグすることで、現在の変数の値や、処理がどのように進んでいるのかを確認できます。デバッグによってプログラムが意図した動作になっているかの分析に役立てられます。 本記事ではGoogle Chromeブラウザーの「Chrome Developer Tools」（以下「デベロッパーツール」、「DevToolsデブ・ツールズ」という略称もあります）を使用してJavaScriptをデバッグする際の基本的な使い方を解説します。「今までデベロッパーツールを使ったことのない」という方でもこの記事を読めば理解できるよう、チュートリアル形式になっています。20分ほどで理解できるようまとめているので、順番に試しながら読み進めてください。 この記事で学べること デベロッパーツールの使い方 JavaScriptのブレークポイ
メモリダンプと模様が見える男｜kamezawa.hiroyuki
10年以上前の昔話であり、そんなこともあったのねという話。あるいはエンタープライズサポートってそんなことやってるのねという話。 カーネルメモリダンプLinuxカーネルをエンタープライズに使おうとした企業、富士通やIBM、日立といった企業がこぞってカーネルに入れようとした機能がカーネルがパニックした時に「なぜコケたのか」調べるための機能であった。その最たるものがメモリダンプだった。この機能はカーネルパニックが起きた後のメモリをディスクに吐き出す。この吐き出されたメモリイメージをダンプと呼び、これをデバッガに食わせて原因調査をする。 カーネルデベロッパはパニックが起きたら再現条件を探して理詰めでバグを探すのが得意だが、顧客先でパニックが起きたら「再現させてくれ」とは中々言えないのでこの機能はサポートには重要だった。そして、ダンプ調査の技を持つエンジニアも居た。 地雷型メモリ破壊パニック色々と調
TOMCAT殺害事件 - Qiita
OOMKillerの殺意 顧客EC2のTomcatがアクセスの無い早朝にもかかわらずOOMKillerに突然殺されてしまったので、調査した顛末をたぶん同じような問題に直面されている方もおられるかと思いますので備忘録として記載します。 Javaヒープのチューニングにも多少役立つかと思います。 （この記事はJava8が対象となります。） OOMKillerとはOut of Memory時に、サーバ全体を守るためにメモリーを消費しているプロセスを停止するLinuxの標準機能です。 そのOOMKillerになんとTomcatが突然殺害されてしまいました。 問答無用の辻斬り状態です。 早朝ですのでアクセスログには何も記録されておらず、catalina.outには OpenJDK 64-Bit Server VM warning: Setting LargePageSizeInBytes has no
ftraceの仕組みとアーキテクチャ
はじめにじっくりとライトブーストの仕事をする予定だったのに, ライトブーストのテストにはsystemtapを使いたいなぁとか妄想してたら, 気づいたらftraceについて調べていたので一段落ということでメモっておく. 参考資料としては, “Linuxカーネル Hacks"の8章と, カーネルのソースコードと, ネット上に転がっている文書もろもろ. 理解した内容については, Twitterで散々つぶやくも片っ端から無視されてしまったので, 完全に独断によるものだから(想像も多く含まれる), 正しいかどうか分からないが, 誤っていたら/補足があれば, 今度こそTwitterで指摘して. 色々調べてしまったので, 検討の結果, いくつかの記事に分離して書くことにした. 2-3個になると思う. ftraceの基本原理ftraceの仕事は, 名前の示すとおり, 関数単位である. 関数単位で, 「それ
Ftraceでカーネルの一部の処理を追いかける方法 - Qiita
ftraceのfunctionトレーサやfunction graphトレーサを使うと、カーネルの関数呼び出し処理を追いかけることができます。 ftraceの諸機能をカーネルで有効にする方法については前回の投稿を参照してください。ただし今回書いている内容は、恐らくFedoraやUbuntuのカーネルではデフォルトで有効になっています。 関数コールトレーサ ftraceにはLinuxカーネル内の関数呼び出しをトレースする関数コールトレーサ・関数コールグラフトレーサをサポートしています。 関数コールトレーサはfunctionを、関数コールグラフトレーサは function_graph を、/sys/kerne/debug/tracing/current_tracerに書き込むだけで利用できます。 これらの関数コール（グラフ）トレーサは、インライン展開されていないすべての関数呼び出しをトレースし、
メモリダンプから.NETのメモリ状態を探りたい - Grani Engineering Blog
こんにちは、@mayukiです。 以前、このブログにてダンプ解析入門 - Visual Studioでの可視化によるC#トラブルシューティングというスタックオーバーフローのような問題を調査する方法について触れましたが、今回はダンプを元にメモリ周りの状態を見ていく方法について調べたので少しまとめてみました。 長い時間実行するようなアプリケーション(アプリケーションサーバーなど)ではメモリの使用状況やメモリリークなどを調査したいというケースがたまにやってきます。そんなときにはプロセスのメモリダンプを取得して解析することで問題の原因がわかりそう…そんなシチュエーションで役立つかもしれません。 お品書き お品書き 前提 メモ: 64bit コンピューターで動作している32bit プロセスのダンプをとる ダンプのみどころ どのツールで解析すれば? Visual Studioを試してみる DebugD
エンジニア・光成 滋生の「バグを突き止める技術」 | サイボウズ式
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第18回（これまでの連載一覧）。サイボウズ・ラボの光成 滋生さんにお話を伺うシリーズ（1）です。 本連載は、「WEB+DB PRESS Vol.80」（2014年4月24日発売）に掲載された「エンジニアの学び方──効率的に知識を得て，成果に結び付ける」の続編です。（編集部） 文：西尾 泰和 イラスト：歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第2弾は、サイボウズ・ラボのエンジニアとして、楕円曲線などの難しい数学を使った暗号の論文を読んで実装したり、サイボウズが遭遇した問題の原因を掘り下げていって最終的にLinuxのバグを修正したり、と幅広い活動をされている光成滋生さんです。 光成さんが、どういうプロセスで問題の原因を
デバッグのアンチパターン | EarOwlの日記 | スラド
その1 : 問題が再現する状況を確認した後、『ここを変えたらどうなる?』『こういうパターンではどうなる?』といったことを思いつくままに色々試していく。 『原因の調査のために、情報はとにかく多いほうが良い。』それは間違ってはいないが、思いついたパターンを闇雲に試すだけでは、情報も増えるがそれ以上にノイズが増えていることが多い。 (ひどい場合には必死になってノイズばかりを拾っていることも。) 現象を 1回確認したら、まずはそこから最大限まで情報を得て、原因を絞り込む。その上で、絞り込めない部分があればその部分を確認するための動作を試してみる。このような方法で進めていく方が、大抵の場合はより速く原因に辿りつくことができる。 その2 : 問題が発生した『後』の動作を延々と追いかける。 原因が何であるかにもよるが、ひとたび問題が発生したらそこから先の動作は進めば進むほど予測不能となっていく場合は多い
最適なデバッグは可能性を潰していく事 - 神様なんて信じない僕らのために
minekoaさんのエントリを読んでいて、 「そうそう、コンパイラがこんなこと言うときは実際にはあんな事が起きてるんですよ」みたいな知識データベース。そしてコンパイラが検出出来ないタイプのバグについても、現象に「あれ？、どこかでみたぞ、これ」となる。そういう「良くあるパターン」の蓄積はデバッグのスピードアップに大きく貢献します。 正しい。けれど、それはそれとして。 根本的な問題として、「問題の切り分け」というのが出来ていないからデバッグ出来ないというのが、「デバッグができないこと」なのではないかと思います。 デバッグという基礎素養 - みねこあ 「最適なデバッグはまず適切で高い可能性から潰していく事、最後に残った事が真実」 だなあと思いました。 デバッグをするときに経験があると 「そうそう、こういうときはこれだよね」 というのが解ります。 ハングアップが一番簡単で、 スタックを見ても良いし
経験の浅いプログラマーがデバッグできない理由
経験の浅いプログラマーがデバッグできない理由 「大半の人間がデバッグできない理由」を読んで思いついたことを書きます。 Lights Out っていうパズルゲームがあって、 これは1つのランプを消すと、周りのランプがつく、みたいなルールになっていて、 それを全部消すというゲームです。 たとえば Lights Out - 2 Flash Games, Lights Out Game とか。 今は入手できないのですが「牡丹灯籠」という実装が好きでした。 通常の Lights Out だと消えてるランプをクリックできるのですが、 牡丹灯籠はできなかったんじゃなかったかな、たしか。 ルールもそうだし、グラフィックが切なくてよかったですねー。 んで、ゲームをするとして、とりあえずいろいろクリックしていくわけですね。 そんで、自分の知ってるパターンに収束したら、 あとはパターンに沿って消していけば全部消
デバッグという基礎素養 - みねこあ
経験の浅いプログラマーがデバッグにてこずってるのって、 これと似ていて、 むやみやたらにクリックするのだけど、 自分の知ってるパターンに収束させることができない、みたいな。 これについては、経験を積めば、 自分の知ってるパターンが増えてきて、 バグだ、と思ったときには既に自分の知ってるパターンだから直せる、とか、 ちょっと試行錯誤すればパターンに落とし込めるとか、 そうなるんじゃないかな、と。 経験の浅いプログラマーがデバッグできない理由 については、コンパイラの吐くエラーが実は直接的が原因を示していない、とか、そういうレベルの話では実感だな、って思います。 「そうそう、コンパイラがこんなこと言うときは実際にはあんな事が起きてるんですよ」みたいな知識データベース。そしてコンパイラが検出出来ないタイプのバグについても、現象に「あれ？、どこかでみたぞ、これ」となる。そういう「良くあるパターン」
FreeBSD Press No.12 NetBSD column カーネルデバッグのヒント
このテキストはFreeBSD Press No.12 特集「BSDで動かそう 後編」のNetBSD関連記事のコラムとして掲載されたものです。Webでの公開にあたり投げやりなhtml化を含め一部の表記は見直していますが、記事の内容は当時のままであり、最新のNetBSDバージョンにおける変更には追従していません。記事の内容に関わるような大きな変更は入っていませんが……。 本テキストの著作権は筒井泉が有しています。obsoleteな不正確な情報が拡散するのもあまりよろしくないので、転載は控えて下さい。 デバイスドライバ作成時に限らずカーネルのデバッグというとなにか特別な手法が必要な気がするかもしれないが、実際には単純な手法でも十分役に立つ。それらのいくつかについて紹介する。 基本は printf() とシリアルコンソール? カーネルデバッグのツールとしては内蔵デバッガのDDBやgdbによるcra
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Debug-application-inside-Kubernetes-using-Linux-Kernel-tools
Debugging UEFI applications with GDB - OSDev Wiki
bash recursive xtrace
https://jasst.jp/symposium/jasst16tokyo/pdf/E2.pdf
http://blog.kiftwi.net/2012/03/20/summary-of-pry-plugins/