サンプリングに依る動的なコールグラフを作成する方法はいろいろあるけど、これだとサンプルが取得できないパスに関してはコールグラフが取得できないことになってしまう。ソースコード読みをしているときなど完全なコールグラフがほしい時もあって、その方法を考えた。

SystemTap を使うと、すべての関数呼び出しのトレースを取得できる。これを解析すれば完全な動的コールグラフが作成できる。ところが、トレースからコールグラフを作るいいツールがない。

一応、小さいトレースなら、 vonnyfly/kernel_visualization が使えるけど、内部の作り的にトレースをいったんメモリにため込むので、大きなトレースを食わせるとメモリを食いつぶして死んでしまう。用途に合ったものがなければ作るしかないということで、大きなトレースでも扱えるプログラムを C++ で書いた。本来は SystemTap 内でコールグラフを作るのがスマートなんだけど、いまいち stp ファイルの作り方勉強してないからなぁ・・・というところ。

ちなみに SystemTap のトレースは SPEC2006 bzip2 の test 入力で 4GByte 超える。でかすぎ。

C言語で書かれたプログラムのコールグラフを作成する方法についてのメモ。

コールグラフとは

Wikipediaのコールグラフの項から定義を拝借。

コールグラフ (マルチグラフとも呼ばれる) とは、コンピュータプログラムのサブルーチン同士の呼び出し関係を表現した有向グラフである。

プログラムの解析をしていると、関数の呼び出し関係を視覚的に見たい時がある。そんな時には迷わずコールグラフを描いてみるといい。

静的・動的なコールグラフ

コールグラフには、静的なコールグラフと動的なコールグラフの２通りがある。静的なコールグラフとは、プログラムの実行を伴わずに作成するもの。静的なコールグラフはソースコードのみを解析することで得たり、プログラムをコンパイルする時の情報を使って作成する。コールグラフに存在する関数呼び出しがプログラムを実行したときに起こるかどうかはわからない。

一方、動的なコールグラフは、実際にプログラムを実行したときに起きた関数呼び出しに基づいて作成される。そのため、作成にはプロファイラを用いる。動的なコールグラフにおける関数呼び出しは実際に発生したものであるが、入力に依存する。

解析するときに知りたい情報によってどちらのコールグラフを作るのが望ましいか判断する必要がある。網羅的に関数呼び出しを表現したければ静的なコールグラフを作成するべきだし、とある条件下（入力・環境）におけるプログラムの動作を解析したければ動的なコールグラフを作成するべきだ。また、静的なコールグラフでは大規模になりすぎてみるべきポイントを絞れないといった場合に動的なコールグラフから見て実際に動いてる部分から解析するというアプローチもありだろう。

静的なコールグラフの作成

egypt と codeviz というツールが有名どころなようだ。今回は egypt を用いた。使い方は少し調べれば出てくるから、ほかのサイトを見てもらうとして、自分が使った時に調べた点をいくつかメモしておく。

• egypt をインストールするときに prefix を変える方法が謎。
• gcc には -fdump-rtl-expand オプションをつける。
• 複数のファイルからなるプログラムの場合、.extend ファイルを cat して egypt に与えれば良い。（cat しなくても *.extend みたいな感じでもいいのかもしれないが試していない。）
• gcc が最適化により関数をインライン化するとコールグラフの結果が変わる。例えば、実際には呼び出されている関数が一度も呼び出されないかのような結果が出力される。ソースコードに忠実なコールグラフを得たければ最適化を無効化するべき。
• 横向きで出力した方が見やすい気がする。dot で A4 横向きで出力するためには、以下のように指定する。
  -Gsize=11.7,8.3 -Grankdir=LR
• dot で ps ファイルを出力して、ps2pdf で pdf 化しようとすると、横向きがうまく出力されない。おとなしく dot で -Tpdf を指定して初めから pdf で出力すべき。

動的なコールグラフの作成

こちらも複数ツールがあるようだが今回は gperf2dot.py を利用した。名前に gperf とついているが、gperf だけでなく他のプロファイラの出力も読み取ってくれる。こちらも基本的な使い方はほかのサイトを見てもらうとして、ポイントをメモしておく。

• gperf2dot.py は縦書き表示に適したように作られているっぽい。A4 縦で出力するためには、dot に以下のように指定する。
  -Gsize=8.3,11.7

概要

cron で処理した結果がメールで送られてくるときに /var/spool/mail/username に届く。mbox 形式で書き込まれて、これは mailx で読んだり消したりできる。だけど、mailx は対話式のプログラムで自動で中身を見て処理したりできない。

メールの数が大量になると（例えば毎分スクリプトを回してたりすると）チェック不能になるし、かといってメールを送らないようにするのはちょっと・・・みたいな時に使えます。

procmail とかで受信時に処理するという手もあると思うけど、今回はまとめてバッチ処理する方法を探してみた。

動作環境は CentOS 7 + Python 2.7。

大雑把な手順

1. GNU Mailutils の movemail で /var/spool/mail/username を別のディレクトリ（ホームディレクトリ）に移動
   • /var/spool/mail/ はユーザ権限で新しいファイルを作れないので、mbox ファイルを編集するときにロックが取れないという問題があるので、予めメールを移動
2. mbox を解釈できるライブラリ等を使って mail を解釈して処理
   • 使えるツールはいろいろあると思うが今回は python を使用
   • cron から送られてくるメールに対してテストケースを書いて特定の条件（エラー等）を満たすメールだけを残す、とか特定のファイルに書き出す、とかの使い方を想定

GNU Mailutils のインストール

CentOS のリポジトリにはなさそうだったので公式サイトからダウンロードしてコンパイル・インストール。configure -> make -> make install のいつもの流れで OK。

メール処理スクリプトの例

• $MAIL が設定されていることを前提（/var/spool/mail/username とかになっているはず）
• $HOME/mail/INBOX をメールの移動先とした（予め $HOME/mail を作っておく）
• GNU Mailutils のツールにはパスを通しておく
• このままは動かないのでご注意

#!/usr/bin/env python

import os
import subprocess
import mailbox

def chkMsg(msg):
    subject = msg["subject"]
    body = msg.get_payload()

    # メッセージの内容によって返り値を変える
    if 削除:
        return 0
    else:
        return 1

mboxpath = os.environ["HOME"] + "/mail/INBOX"
subprocess.call(["movemail", os.environ["MAIL"], mboxpath])

mbox = mailbox.mbox(mboxpath)
to_remove = []
for key, msg in mbox.iteritems():
    if chkMsg(msg) == 0:
        print "Removing: ", key
        to_remove.append(key)

mbox.lock()
try:
    for key in to_remove:
        mbox.remove(key)
finally:
    mbox.flush()
    mbox.close()

subprocess.call(["mail", "-f", mboxpath])

参考

• 18.1.1. email.message: 電子メールメッセージの表現
• 18.4. mailbox — 様々な形式のメールボックス操作
• Issue 7359: mailbox cannot modify mailboxes in system mail spool
• mailbox – メールアーカイブのアクセスと操作

$ qalter -l walltime=X jobid

参考：is there a way to change the walltime for currently running PBS job