From owner-freebsd-emulation@FreeBSD.ORG Wed Sep 19 10:34:19 2007 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62C6416A46C; Wed, 19 Sep 2007 10:34:19 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0A02F13C4E7; Wed, 19 Sep 2007 10:34:18 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from doc.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IXwsq-000PSD-RU; Wed, 19 Sep 2007 14:34:17 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IXwuL-000Cjj-Oa; Wed, 19 Sep 2007 14:35:49 +0400 To: Roman Divacky References: <20070917152625.GA507@freebsd.org> <64815375@srv.sem.ipt.ru> <46EF62C5.5090704@gmail.com> <00483937@srv.sem.ipt.ru> <46EF7E05.5040405@gmail.com> <20070918074332.GA30053@freebsd.org> <88000019@srv.sem.ipt.ru> <20070918082119.GA30932@freebsd.org> <89768331@srv.sem.ipt.ru> <41596338@srv.sem.ipt.ru> <20070919085405.GA24442@freebsd.org> From: Boris Samorodov Date: Wed, 19 Sep 2007 14:35:49 +0400 In-Reply-To: <20070919085405.GA24442@freebsd.org> (Roman Divacky's message of "Wed\, 19 Sep 2007 10\:54\:05 +0200") Message-ID: <18395962@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-emulation@freebsd.org, sam Subject: Re: linuxolator problem on i386 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 10:34:19 -0000 On Wed, 19 Sep 2007 10:54:05 +0200 Roman Divacky wrote: > > It so happened that here we get a deal with magic (number). Let me > > show you the broken behaviour one more time: > > 14594 hlds_i686 CALL linux_getdents(0x6,0x8da5b44,0x1000) > > 14594 hlds_i686 RET linux_getdents 4096/0x1000 > > Look at the first linux_getdents() line. The third parameter (buffer > > length?) equals to 0x1000 which is 4096. The second line with > > linux_getdents shows that it has read precisely 4096 (bytes?). What if > > we face here a (so called at our high school) border-case > > (border-problem)? > > > > OK, the program reads the directory contents. Lets touch a new file > > at this directory. What does happen? Follow me: > > 14579 hlds_i686 CALL linux_getdents(0x6,0x8da574c,0x1000) > > 14579 hlds_i686 RET linux_getdents 4084/0xff4 > > > That's it! > > > > Roman, I hope now you may create the needed patch. > > As for me I'm too tied (and too proud :-) ) today and 'm going to have > > a little sleep. > I am sorry but I dont understand at all.. what are you trying to show? > whats wrong with returning 4084? Sorry to be laconic. There is nothing wrong with 4084. The magic 4096 is the answer. I.e. the first case (when a buffer is equal to that has been really read) is wrongly processed. Ex. in C strings ends with 0x0. If a buffer 4096 bytes long was assigned a string 4096 bytes long then the 0x0 will become a 4097 byte. And this string will cause a fault of the program. PS. I don't say that I gave a strict example of the case. Of cause it may be something else. But definitely there is a bug in processing of 4096 bytes log strings by our linuxulator code (somewhere at the linux_getdents area, linux_getdents64 used by linux_base-fc4 is not affected by _at least_ 4096 bytes long strings). Hm, is my current explanation more understandable? WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve