2005年6月19日 (日曜日)

08:15:43 # Life soundtrackerとgamixにドイツ語訳のアップデートのパッチが来たので対応してみる． language coordinatorとかが頑張っているところだと思うのだけど，そういうのの存在を Jens Seidelさんはしらずに大量にバグレポートを投げている？

09:00:11 # dupload 今日のDebianパッケージメンテナンスはbinfmtc．binfmtcの0.6-1をここらへんに置いてみる．

10:22:41 # Life 朝からdpatchについてハックする． とりあえず，挙動が変なのとドキュメントとコードが一致していないため， testsuiteを追加した．

16:42:38 # Life planetにはツッコミSPAMがもろにつっこまれるので， こまった． 正規表現とかでRSSのエントリーを除外とかできないだろうか． できそうでできないこのかゆさ．

20:44:01 # Life メモリの確保はどうなっているんだろう，と思い，調べてみた． glibcのmallocのソースコードから見ると，サイズで分岐して， brkを使う場合とか，mmapを使う場合とかで一番経験的にはやいものを選択しているような雰囲気．

テストプログラムを動かしてみると，最初の挙動と後の挙動がちょっとちがう． 期待していたのは同じような動きを繰り返してくれることなのだが，いちど大きな領域を確保すると 挙動がかわってしまうようだ． 一度確保した領域はOS側に返却していないからかな． 実行中のアプリケーションをtopで見ると，VIRTサイズがkB単位から1GB程度 までくるくるまわっているのがわかる．

/*BINFMTC:
 */
#include <stdio.h>
#include <stdlib.h>

main()
{
  int i;
  while (1) 
    {
      for (i=1; ; i<<=1)
	{
	  void*ptr;
	  ptr=malloc(i);
	  if (!ptr) break;
	  printf ("%i %p\n", i, ptr);
	  free(ptr);
	}
    }
}
	

1 0x804a008
2 0x804a008
4 0x804a008
8 0x804a008
16 0x804a018
32 0x804a030
64 0x804a058
128 0x804a0a0
256 0x804a008
512 0x804a008
1024 0x804a008
2048 0x804a008
4096 0x804a008
8192 0x804a008
16384 0x804a008
32768 0x804a008
65536 0x804a008
131072 0x804a008
262144 0xb7f49008
524288 0xb7f09008
1048576 0xb7e89008
2097152 0xb7d89008
4194304 0xb7b89008
8388608 0xb7789008
16777216 0xb6f89008
33554432 0xb5f89008
67108864 0xb3f89008
134217728 0xaff89008
268435456 0xa7f89008
536870912 0x97f89008
1073741824 0x77f89008

	  [中略]

1 0xb7e00480
2 0xb7e00480
4 0xb7e00480
8 0xb7e00480
16 0xb7e00490
32 0xb7e004a8
64 0xb7e004d0
128 0xb7e00518
256 0xb7e00480
512 0xb7e00480
1024 0xb7e00480
2048 0xb7e00480
4096 0xb7e00480
8192 0xb7e00480
16384 0xb7e00480
32768 0xb7e00480
65536 0xb7e00480
131072 0xb7e00480
262144 0xb7f49008
524288 0xb7f09008
1048576 0xb7cff008
2097152 0xb7bff008
4194304 0xb79ff008
8388608 0xb75ff008
16777216 0xb6dff008
33554432 0xb5dff008
67108864 0xb3dff008
134217728 0xafdff008
268435456 0xa7dff008
536870912 0x97dff008
1073741824 0x77dff008
	

20:50:52 # Life Cプログラムのメモリマップはどうなっているのだろう，と調査． gdb上で実行して停止して，ちょうどglibcにはいっているところで止める． btをとってみてそれと/proc/XX/mapsと比較する． /proc/XX/mapsに書いてある仮想アドレスにコードがロードされており， スタック上にそのアドレスがちゃんと書いてあるんだな，ということが確認できる． ちょっと安心．

(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x4515fb36 in munmap () from /lib/tls/i686/cmov/libc.so.6
#2  0x450fcd3c in malloc_set_state () from /lib/tls/i686/cmov/libc.so.6
#3  0x08048446 in main ()

$ cat /proc/6905/maps
08048000-08049000 r-xp 00000000 00:0d 9350       /tmp/a.out
08049000-0804a000 rw-p 00000000 00:0d 9350       /tmp/a.out
0804a000-0806b000 rw-p 0804a000 00:00 0          [heap]
45072000-45088000 r-xp 00000000 03:03 1929540    /lib/ld-2.3.2.so
45088000-45089000 rw-p 00015000 03:03 1929540    /lib/ld-2.3.2.so
4508b000-451b5000 r-xp 00000000 03:03 1929543    /lib/tls/i686/cmov/libc-2.3.2.so
451b5000-451be000 rw-p 00129000 03:03 1929543    /lib/tls/i686/cmov/libc-2.3.2.so
451be000-451c0000 rw-p 451be000 00:00 0
b7e00000-b7e21000 rw-p b7e00000 00:00 0
b7e21000-b7f00000 ---p b7e21000 00:00 0
b7f24000-b7f25000 rw-p b7f24000 00:00 0
b7f36000-b7f38000 rw-p b7f36000 00:00 0
bfb23000-bfb38000 rw-p bfb23000 00:00 0          [stack]
ffffe000-fffff000 ---p 00000000 00:00 0          [vdso]
	

21:06:00 # Life あと，codefestの時の宿題を完了する． redirect-processはRubyでかかれていて， それはそれでよいのだが，シェルでも書けるよな，と思って，oneliner. PARAM= で指定したプロセスのstdout を自分のstdoutとして出力してみる例． PARAM=12519 gdb -batch -n -x <( echo -e "attach $PARAM\nprint dup2(open(\"/proc/$$/fd/1\", 1), 1)" )