Re: Out-of-Line memory deallocation: MIG vs. glibc

[Thomas Schwinge]

On Mon, Apr 10, 2006 at 01:32:17AM +0200, olafBuddenhagen@gmx.net wrote:
> A while back, Michael observed that building the debian package of
> zaptel regularily causes the FS in the build chroot to crash. I could
> reproduce that on my system, and tried to hunt down the problem.

Thanks for doing this!


> 1. With the "fakeroot-tcp sh -c" case, the file_exec call receives an
> enormous amount of several hundred port rights for the fdarray[]
> argument (as well as some others)

I can confirm that there are issues.  I placed a printf() call infront of
the exec_exec() call in libdiskfs's file-exec.c to print out `err' and
`fdslen' and can show the following results (created on a dummy 10 MiB
file system, using a non Ogi patched Hurd tree):

#v+
tschwinge@clubber:~/tmp/ext2fs$ sudo settrans -cap ./filesystem.0.i 
/usr/bin/env LD_LIBRARY_PATH=`pwd` `pwd`/ext2fs `pwd`/filesystem.0
tschwinge@clubber:~/tmp/ext2fs$ cd filesystem.0.i/
tschwinge@clubber:~/tmp/ext2fs/filesystem.0.i$ cp /bin/echo ./
tschwinge@clubber:~/tmp/ext2fs/filesystem.0.i$ sh -c `pwd`/echo\ foo
err = 0 fdslen = 3
foo
tschwinge@clubber:~/tmp/ext2fs/filesystem.0.i$ fakeroot-hurd sh -c `pwd`/echo\ 
foo
err = 0 fdslen = 3

tschwinge@clubber:~/tmp/ext2fs/filesystem.0.i$ fakeroot-tcp sh -c `pwd`/echo\ 
foo
err = 0 fdslen = 925
foo
#v-

Might this actually be a fakeroot-tcp (which is from the Debian fakeroot
package) problem?

Uh, and what's up with the example in the middle?

#v+
[...]
tschwinge@clubber:~/tmp/ext2fs/filesystem.0.i$ cat echo_args
#!/bin/sh

echo $# "$@"
tschwinge@clubber:~/tmp/ext2fs/filesystem.0.i$ sh -c `pwd`/echo_args' a b c'
err = 0 fdslen = 3
3 a b c
tschwinge@clubber:~/tmp/ext2fs/filesystem.0.i$ fakeroot-hurd sh -c 
`pwd`/echo_args' a b c'
err = 0 fdslen = 3
0
tschwinge@clubber:~/tmp/ext2fs/filesystem.0.i$ fakeroot-tcp sh -c 
`pwd`/echo_args' a b c'
err = 0 fdslen = 925
3 a b c
#v-

What's up with the Hurd's fakeroot?


> so many [port rights for the fdarray[] argument] that they are
> automatically transferred out-of-line, which is one of the conditions
> causing the crash. I wonder whether this is some bug by itself.

Could you please elaborate on that?


Regards,
 Thomas