From owner-freebsd-emulation@FreeBSD.ORG Sun Nov 30 22:19:43 2008 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 C51261065670 for ; Sun, 30 Nov 2008 22:19:43 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from istc.kiev.ua (wolf.istc.kiev.ua [193.108.236.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7E63D8FC08 for ; Sun, 30 Nov 2008 22:19:42 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from [91.123.146.100] (helo=ravenloft.kiev.ua) by istc.kiev.ua with esmtp (Exim 4.52) id 1L6udf-0000E2-EU; Mon, 01 Dec 2008 00:19:39 +0200 Date: Mon, 1 Dec 2008 00:19:35 +0200 From: Alex Kozlov To: Gerald Pfeifer , Tijl Coosemans , Daichi GOTO , freebsd-emulation@freebsd.org, spam@rm-rf.kiev.ua Message-ID: <20081130221935.GA79764@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 2.0 (++) X-Spam-Report: Content analysis detailz: (2.0 points, 10.0 required) * 2.0 DNS_FROM_SECURITYSAGE RBL: Envelope sender in * blackholes.securitysage.com Cc: Subject: Re: wine-1.1.8 regression -- wine: could not load L"...": Invalid address 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: Sun, 30 Nov 2008 22:19:43 -0000 On Sun, Nov 30, 2008 at 06:58:14PM +0100, Gerald Pfeifer wrote: > On Wed, 26 Nov 2008, Alex Kozlov wrote: >>> The patch moves this to (address_space_limit - 10 * VIRTUAL_HEAP_SIZE). >>> I'm not sure that's correct. I think simply 0x80000000 would be better, >>> but that's what Alexandre can tell you. >> I'm also not sure. That why this patch quick and dirty. Let see what >> Julliard has to say. >From Alexandre POV most correct action will be to fix reserve_areas logic on FreeBSD. (I try that on this weekend, but with limited success. Very limited. Need more work, and I'm not sure that I will have enough time) As for the patch, place when alloc virtual_heap don't matter. So I think 0x80000000 is ok. > Thanks again, Alex, and thanks for the review, Tijl! (I had the same > question on the second hunk. ;-) This is garbage from my attempts to fix reserve_area. Sorry. -- Adios