bug with vfork, execv

bug with vfork, execv

[Harry Kalogirou]

Hi all,
 now that the kernel supports a growing stack I was able to observe an
bug concering vfork and the way libc finds the current heap ending
point(brk).

Suppose that the shell has its t_endbrk at 0x3000. Libc also keeps this
value in a variable, and that variable is in sync with the kernel. Then
it executes a vfork() (parent waits and shares code and data with the
child) and the child calles execv(). In execv() the sbrk() is called to
enlarge the heap by 0x10 for example. sbrk() calles sys_brk() to enlarge
the heap(now the child has a t_endbrk of 0x3010) and also updates the
current brk position in the variable(the variable now also is 0x3010).
The problem is that this variable is shared with the parent, so the next
time the shell will vfork and execv again will request further memory
since the brk variable is 0x3010 now. So after every vfork-exec the
shell will request for 0x10 bytes more.

The solutions I see are :

1) Remove vfork() and make it just a fork().
2) Change the way sbrk() works in the libc, probably by changing it to  
request the current brk position from the kernel.

I would like to hear your opinions.

Harry

Re: bug with vfork, execv

[Harry Kalogirou]

> Hi all,
>  now that the kernel supports a growing stack I was able to observe an
                                           ^
I mean heap here --------------------------

> bug concering vfork and the way libc finds the current heap ending
> point(brk).