Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of xiaofeng.li@gmail.com
 designates 209.85.132.242 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=D3JqxgZwJjtdKjxgPNmWoqgCBcxdEwbpe7wc9FamErMvueenEzHEA7rQGcMPYS6Ijpm3HbrB5vrY6Aw3sGimDxsc2XNXM6iqoGuQZ4z9+Fqn8iDhjoueMMYIp7ZN6hOp2cCtMCB1E1wh4hXEgcTSItv6xiK5iNn8y5x8pbiTS10=
Message-ID: <9623c9a50711121330t4e57da56p361e5f6d438e3e38@mail.gmail.com>
Date: Tue, 13 Nov 2007 05:30:57 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][GC]Bad Pointer during GC v5 shutdown sequence
In-Reply-To: <32259710711120546x2cd1a3c4n63e12ba9e3165665@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <32259710711090840y3bc910c1s2e7ae332878b0029@mail.gmail.com>
	 <51d555c70711101113y7ca173b9v55b042966048f62c@mail.gmail.com>
	 <32259710711120546x2cd1a3c4n63e12ba9e3165665@mail.gmail.com>

The patch is great. Some improvement is necessary before committing.
Please check the comments I put in the JIRA issue.

Thanks,
xiaofeng

On 11/12/07, Ilya Leviev <ilya.leviev@gmail.com> wrote:
> Rana,
>
> Thank you for evaluation and a quick patch. It seems that the patch
> you have prepared solves the problem with invalid pointer.
>
> To check that the patch fixes the memory leak I've applied your patch
> and rerun BoundsChecker. The tool detected no leek related to this
> issue with your patch applied. Thank you again for the great job: your
> patch decreased leaks by 256 MB!
>
> Best regards,
> Ilya.
>
>
> On 11/10/07, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> > Illya,
> > Yes, it's possible that there could be a leak. An assert added to
> > vm_unmap_mem() does show that the VirtualFree fails. The pointer parameter
> > etc. passed to the function are invalid because the sections of the heap (
> > nos, mos etc. ) have already been freed with STD_FREE.
> >  The root cause is that for VirtualFree() to successfully release on
> > Windows, it needs to be called from the exact VirtualAlloc allocation base.
> > I have attached a quick fix in
> > H5105<https://issues.apache.org/jira/browse/HARMONY-5105>
> > which you can try. Xiao Feng needs to look at it.
> >
> > Rana
> >
>


-- 
http://xiao-feng.blogspot.com