I'm not normally in the habit of forwarding private emails to public
forums, but I thought it might interest someone here why I was asking
what I was asking, as well as what I found out while working on it.
Ehud Karni wrote:
On Sun, 21 Jun 2009 13:04:37 Ehud Karni wrote:
[snip]
You don't have to reply. I did see Shlomo email and your reply just
now because he changed the thread name. I understand your need for
vfork. Just be careful.
In point of fact, I do not need vfork at all. It can be eliminated from
the system calls list altogether, as far as I'm concerned.
Unfortunately, it is GNU make that uses vfork in order to start new
processes.
The reason I care what make does is a project of mine called
"fakeroot-ng" [1]. It attempts to achieve the same broad effect as
fakeroot[2], except using the more thorough PTRACE technology, rather
than LD_PRELOAD like fakeroot. As such, it hooks itself between the run
time library and the kernel (as opposed to between the program and the
runtime library, which is what fakeroot does). The problems there tend
to be somewhat unique, due to glibc's close intimate relationship with
the kernel.
In particular, I am trying to tackle the problem of how to remain
attached as a debugger to a process that spawns a new child process
(threads are a subject I have not even begun working on). Copying ideas
liberally from "strace" (it's insane to try and copy code from there -
the code there is a total mess), I tried turning calls to "fork" into
calls to "clone", adding the CLONE_TRACE and removing the CLONE_UNTRACE
flags. This works for program that call "clone" or "fork", but when the
program calls "vfork", it segfaults after it returns from the syscall.
Of course, in order to debug that properly, it is best to construct a
sample program that does vfork and little else. Of course, if that
program then crashes even without fakeroot-ng, then I've got a program.
This is what the sample program I sent to the list was all about. Thank
you all for your help.
All this is made worse when you consider that, since fakeroot-ng is
already a debugger for the process that segfaults, gdb cannot connect to
it. Anyways, I think I have a fairly good idea on what the source of the
problem might be now, and I'm hoping to get this resolved soonish.
One comment - If the parent failed when you returned from call in the
child, It is proof that at least the stack memory was common to both.
sys_vfork calls do_fork with CLONE_VFORK|CLONE_VM. The first means
"return to parent only after child releases the VM" (i.e. - calls exit
or execve), while the second means to have the two share the same VM. As
such, yeah, the stack is commune when calling vfork.
Of course, this means that the function "vfork" as implemented in glibc
needs to do some magic in order to not trash the stack when it returns.
I believe it is this magic that causes the segfault. Still looking into it.
Shachar
Ehud.
--
Ehud Karni Tel: +972-3-7966-561 /"\
Mivtach - Simon Fax: +972-3-7976-561 \ / ASCII Ribbon Campaign
Insurance agencies (USA) voice mail and X Against HTML Mail
http://www.mvs.co.il FAX: 1-815-5509341 / \
GnuPG: 98EA398D <http://www.keyserver.net/> Better Safe Than Sorry
--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com
_______________________________________________
Linux-il mailing list
[email protected]
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
