[MD:2822]Portable dumper

[Yoshiki Hayashi <yoshiki@xxxxxxxxxx>]

Keiichiro Nagano (永野圭一郎) <knagano@xxxxxxxxx> writes:

> 僕の手元は、Linux kernel 2.2.19, gcc 3.0.3, GNU binutils 2.11.2 です。
> たぶん CVS の外では最新だと思います。

こっちは Linux kernel 2.4.18pre2, gcc 2.95.4, GNU binutils
2.11.92.0.12.3 という変な環境です。(Debian unstable + ちょっ
と前の pretest kernel)

> (gdb) up
> #1  0x080e2ae9 in mark_object (argptr=0xbff8c) at alloc.c:2317
> 2317          abort ();
> (gdb) p obj
> $1 = 2147483647
> (gdb) xtype
> Lisp_Type_Limit
> 0
> (gdb) up
> #2  0x080e295d in mark_object (argptr=0x44f24) at alloc.c:2208
> 2208            mark_object (&ptr->function);
> (gdb) p obj
> $2 = 786308
> (gdb) xtype
> Lisp_Int
> 0
> (gdb) up
> #3  0x080e2a39 in mark_object (argptr=0xc23c0) at alloc.c:2253
> 2253                mark_object (&ptr->buffer);
> (gdb) p obj
> $3 = 537153308
> (gdb) xtype
> Lisp_Misc
> Lisp_Misc_Buffer_Local_Value
> (gdb) up
> #4  0x080e294f in mark_object (argptr=0xeb2d4) at alloc.c:2207
> 2207            mark_object ((Lisp_Object *) &ptr->value);
> (gdb) p obj
> $5 = 795580
> (gdb) xtype
> Lisp_Int
> 0
> (gdb) up
> #5  0x080e2910 in mark_object (argptr=0xc22ec) at alloc.c:2195
> 2195                mark_object (&ptr1->contents[i]);
> (gdb) p obj
> $6 = 0
> (gdb) xtype
> Lisp_Int
> 0
> (gdb) up
> #6  0x080e295d in mark_object (argptr=0xeb294) at alloc.c:2208
> 2208            mark_object (&ptr->function);
> (gdb) p obj
> $7 = 795364
> (gdb) xtype
> Lisp_Int
> 0
> (gdb) up
> #7  0x080e2910 in mark_object (argptr=0xc22d4) at alloc.c:2195
> 2195                mark_object (&ptr1->contents[i]);
> (gdb) p obj
> $8 = 1
> (gdb) xtype
> Lisp_Int
> 0
> (gdb) up
> #8  0x080e295d in mark_object (argptr=0xeac60) at alloc.c:2208
> 2208            mark_object (&ptr->function);
> (gdb) p obj
> $9 = 795340
> (gdb) xtype
> Lisp_Int
> 0

どうも GC が stack と heap を壊してしまったようで、最初の時
点でかなり怪しそうな感じがします。(Lisp_Int の mark_object
が stack 上にあらわれるのはおかしい)

Qnil や Qt, Vobarray などがちゃんと書き戻されているかを 
xtype, xsymbol, xvector などで調べてみてください。後、xptrで
出てくる address が pdump_objects_start から、
pdump_objects_start + pdump_header.objects_size 内にあるかど
うか調べると便利です。もちろん、新たに malloc された
Lisp_Object は別の領域にありますが、起動時に多数を占める 
dump された object は必ずその領域内にあります。
break Fgarbage_collect して、Qt などを調べる前に GC が一度も

どうも他の人のところでは動いていないようなので、ちょっと 
heap の test 用 code を書いてみることにします。

阿部さんの方は、Debian unstable ということなので、
cd src; make clean; make LDFLAGS='-L/usr/X11R6/lib -znocombreloc'
でやってみてください。
# 私の環境は Debian unstable なので、そこでは動くはずなんで
# すが...

今は、非常に大きな address に mmap されると落ちるという再現
可能な問題があるので、それを追っかけています。
# Solaris での問題はこれ。Windows への移植までの道のりは長そ
# う。(;_;)

と書いていて、いろいろ試していると、Desktop の方 (ちょっと古
い Debian unstable) で再現するようなので、調べてみます。

-- 
Yoshiki Hayashi