Help - can anyone explain this segfault?

[Shachar Shemesh]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20090621/bdcd480e/attachment-0001.html>