From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harry Kalogirou Subject: bug with vfork, execv Date: 01 Nov 2002 22:19:21 +0200 Sender: linux-8086-owner@vger.kernel.org Message-ID: <1036181894.16096.60.camel@cool> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: List-Id: Content-Type: text/plain; charset="us-ascii" To: Linux-8086 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