http://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/jpdnvc60/htm/MemLeaks.asp
参考文献が関係なさすぎワロタ
それにしてもこの作者、ノリノリである
ネタ元はいつものようにshinh先生
補足情報
以下の記事では、特に MFC アプリケーションを中心として、メモリ リークのデバッグについて論じています。
(略)
孫子著『兵法』、取扱出版社多数。
メモリ リークのデバッグにはまったく関係ありませんが、ホワイトペーパーを書いていて、昔の中国の哲学者の言葉を引用したいと思っている読者には役に立つかもしれません。
参考文献が関係なさすぎワロタ
それにしてもこの作者、ノリノリである
ネタ元はいつものようにshinh先生
So long, and thanks for all the fish.
SDスケジューラで有名なCon Kolivasの引退メッセージである。
素晴らしい。
ちなみに、日本語訳は「さようなら、いままで魚をありがとう」らしい。
そのfishは魚ちゃうやろーーーー
と思っていたら、本人のページにも、そう書いてある。
すばらしい。
本人が魚と主張するなら仕方ないよな。
なんで引退メッセージを日本語で書こうと思い立ったのかはさっぱり分からんが(^_^;
SDスケジューラで有名なCon Kolivasの引退メッセージである。
素晴らしい。
ちなみに、日本語訳は「さようなら、いままで魚をありがとう」らしい。
そのfishは魚ちゃうやろーーーー
と思っていたら、本人のページにも、そう書いてある。
すばらしい。
本人が魚と主張するなら仕方ないよな。
なんで引退メッセージを日本語で書こうと思い立ったのかはさっぱり分からんが(^_^;
ここ数日LKMLでatomic_tにvolatileをつけるの、つけないので盛り上がる。
てかフレーム。
みんな好きだねぇ。。。
もちろん、結論はvolatileじゃ意味ないからmemory barrier張れ、という結論しかないのだが、ここでlinus登場
「データ構造に現れるvolatileは悪いvolatile, コードに現れるvolatileはいいvolatile」とか変な事をいうので根拠を説明せいとフレームに。
linus...
あと、ここでも自転車置き場の議論の法則は有効で、くだんねー話題ほど参加率は増えると再確認。
てかフレーム。
みんな好きだねぇ。。。
もちろん、結論はvolatileじゃ意味ないからmemory barrier張れ、という結論しかないのだが、ここでlinus登場
「データ構造に現れるvolatileは悪いvolatile, コードに現れるvolatileはいいvolatile」とか変な事をいうので根拠を説明せいとフレームに。
linus...
あと、ここでも自転車置き場の議論の法則は有効で、くだんねー話題ほど参加率は増えると再確認。
http://www.chikawatanabe.com/blog/2007/08/13john-rain.html
なんという超展開!
ストーリーよりも、松下電工の法務で働いていたCIA covert operationの作者ってのがハートわしづかみすぎる
ちょwwおまwwww
で、この映画を見て思い出したのが、最近読んだRequiem for an Assassin。アメリカ人と日本人のハーフの殺し屋、John Rainが主人公のシリーズものの最新作。筆者は、自身もCIAのcovert operationで3年間働いたことのあるBarry Eisner。しかも、大阪の松下電工の法務部で働いていたこともあるので、日本の話も詳しいです。
なんという超展開!
ストーリーよりも、松下電工の法務で働いていたCIA covert operationの作者ってのがハートわしづかみすぎる
ちょwwおまwwww
RHEL4にはいってるやつはバージョンが古くてよーわからん。
いや、新しくても分かんかも知れんが(´・ω・`)
いや、新しくても分かんかも知れんが(´・ω・`)
linuxのカーネルダンプ解析に使うcrashというコマンドがある。
かなり強力なツールなのだがgdbと違ってマクロ機能はないっぽい
(あったら誰か教えて!)
で、仕事上、すごーーーく、長大なリスト構造をダンプ解析することになり、手動で調べるのを断念。プラグインを作ってみた
(crashのプラグラインがナニモノかはcrashコマンドプロンプトで crash> help extend と打てば分かるよん)
最初、かなり舐めてたのだが、結構苦労した。
完全ドキュメント0でつね。これ(´・ω・`)
以下、備忘録
・pluginのスケルトンはcrashに付属するecho.c から拝借すると良い
ポイントはいか
- defs.h のインクルードは必須(defs.hはcrashのソースに付属)
- struct command_table_entry の配列を定義する事により、コマンド定義される
- _init(), _fini()はだまってコピー&ペーストするように。 extend echo.so で_init()が呼ばれ、extend -u echo.soで_fini()が呼ばれる
- コマンド引数はグローバル変数 argcnt, args に保存されている
・よく使うコマンドは以下
かなり強力なツールなのだがgdbと違ってマクロ機能はないっぽい
(あったら誰か教えて!)
で、仕事上、すごーーーく、長大なリスト構造をダンプ解析することになり、手動で調べるのを断念。プラグインを作ってみた
(crashのプラグラインがナニモノかはcrashコマンドプロンプトで crash> help extend と打てば分かるよん)
最初、かなり舐めてたのだが、結構苦労した。
完全ドキュメント0でつね。これ(´・ω・`)
以下、備忘録
・pluginのスケルトンはcrashに付属するecho.c から拝借すると良い
ポイントはいか
- defs.h のインクルードは必須(defs.hはcrashのソースに付属)
- struct command_table_entry の配列を定義する事により、コマンド定義される
- _init(), _fini()はだまってコピー&ペーストするように。 extend echo.so で_init()が呼ばれ、extend -u echo.soで_fini()が呼ばれる
- コマンド引数はグローバル変数 argcnt, args に保存されている
・よく使うコマンドは以下
- fprintf(fp, "")
crash端末への出力はグローバル変数fp(この名前は決めうち)にfprintfする
- symbol_value("シンボル")
文字列で与えられたシンボル(グローバル変数名または関数名)からアドレスを返す
- readmem(addr, addr_type, buf, size, "エラー文字列", エラー処理タイプ);
アドレスをあたえて、そのアドレスの値を読む。
典型的にはsymbol_value()の復帰値を与える
addr readするアドレス
addr_type
UVADDR: ユーザ空間仮想アドレス
KVADDR: カーネル空間仮想アドレス(普通は常にこれで十分)
PHYSADDR: 物理アドレス
XENMACHADDR: XENでのマシンアドレス
buf 結果格納バッファ
size readサイズ
エラー文字列: addrが不正などでエラー発生時にこの文字列が表示される
エラー処理タイプ
FAULT_ON_ERROR: 異常時にcrash>プロンプトに強制復帰
(常にこれで実用上は十分)
QUIET|FAULT_ON_ERROR: 上と同じだが、メッセージが出ない(らしい)
RETURN_ON_ERROR: 異常時に関数が0を返す(成功時は1)
QUIET|RETURN_ON_ERROR: 上と同じだが、メッセージが出ない(らしい)
- STRUCT_SIZE("構造体名")
構造体名から構造体のサイズを得る。配列を処理するときに使う
- MEMBER_OFFSET("構造体名", "メンバ名");
構造体中のメンバの構造体先頭アドレスからのオフセットを得る
という本を読んだ。
中学英語と思ってバカにしていたら全然忘れている事がぼろぼろと・・・
技術英語を読むのに使っている語彙がいかに少ないかと痛感した(´・ω・`)
もっと勉強せなな
中学英語と思ってバカにしていたら全然忘れている事がぼろぼろと・・・
技術英語を読むのに使っている語彙がいかに少ないかと痛感した(´・ω・`)
もっと勉強せなな
おかげで、歩いて会社にくるはめに。
暑かった。
電光掲示板には停電とか書いてあったが、人身事故らしい。
死ぬなら人に迷惑をかけない手段をえらんでいただきたい。
暑かった。
電光掲示板には停電とか書いてあったが、人身事故らしい。
死ぬなら人に迷惑をかけない手段をえらんでいただきたい。