From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SPJHf-0005w6-3z for mharc-grub-devel@gnu.org; Tue, 01 May 2012 16:02:51 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44392) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPJHd-0005vl-8S for grub-devel@gnu.org; Tue, 01 May 2012 16:02:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPJHb-0008Nu-Cu for grub-devel@gnu.org; Tue, 01 May 2012 16:02:48 -0400 Received: from mail-qc0-f169.google.com ([209.85.216.169]:46565) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPJHb-0008Np-6a for grub-devel@gnu.org; Tue, 01 May 2012 16:02:47 -0400 Received: by qcsd16 with SMTP id d16so2506878qcs.0 for ; Tue, 01 May 2012 13:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=iuH3jW3ZnB+Mml8e8qNF7m1RYYfoau9tT4mExbSfE5I=; b=lEXrrkOUO9zEBeIrR5l1QroK3uRAtNcpTZrzNVwfbsY3Ge7z34rLGUfVZeESX+aaD+ eoiEOpt5vse0Hvq1p+fYTdhqF/+TpknZNviiLEWD8vOrb91+HMNJzZfRPh3px0OX/bTj gDeKP37s03Ics1adQVXkLGVszCldIk4rioTFu60yjhrCHaufCtfeIaw8jdsMTBmLzsQ+ vPNFTyoe+JsKRfcYUPhkuZYBnBV+t22UzNjtoizr4+QbHDYAeFHwYPkLnJ1aO6ZKtPvw wiyIGjdh6kgg4CM7GQTmNrfyYT69riCcQx2xTL6cPDRwFzK9rZhPt7br5Dn5iEdymzFA NYsA== MIME-Version: 1.0 Received: by 10.229.137.79 with SMTP id v15mr6704268qct.142.1335902565468; Tue, 01 May 2012 13:02:45 -0700 (PDT) Received: by 10.229.222.197 with HTTP; Tue, 1 May 2012 13:02:45 -0700 (PDT) In-Reply-To: <4FA03FF2.30607@gmail.com> References: <4FA034B2.2030400@gmail.com> <4FA03FF2.30607@gmail.com> Date: Wed, 2 May 2012 04:02:45 +0800 Message-ID: Subject: Re: Mysterious memory corruption bug From: Bean To: The development of GNU GRUB Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.216.169 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 20:02:50 -0000 On Wed, May 2, 2012 at 3:56 AM, Vladimir '=F6-coder/phcoder' Serbinenko wrote: > On 01.05.2012 21:52, Bean wrote: >> On Wed, May 2, 2012 at 3:46 AM, Bean wrote: >>> On Wed, May 2, 2012 at 3:08 AM, Vladimir '=F6-coder/phcoder' Serbinenko >>> wrote: >>>> On 01.05.2012 20:53, Bean wrote: >>>>> Hi, >>>>> >>>>> Thanks to Vladimir's memory patch, it's actually quite easy to >>>>> reproduce mysterious issue. >>>>> >>>>> First, there are two memory leaks in ip.c. >>>>> >>>>> It allocates the rsm but never frees it. free_rsm frees its content, >>>>> but not the pointer itself. You can see it in printmem at ip.c:473 >>>>> =A0 =A0 =A0 rsm =3D grub_malloc (sizeof (*rsm)); >>>>> >>>>> Another problem is at ip.c:594: >>>>> =A0 return handle_dgram (ret, card, src_hwaddress, >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0hwaddress,= proto, &source, &dest, >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ttl); >>>>> here, ret is netbuff. grub_netbuff_alloc get a buffer for both data >>>>> and header (data go first), so when it frees the data pointer, the >>>>> header goes away as well. But here, the header is allocated separatel= y >>>>> so that it's not free using , you can see it from printmem at ip.c:58= 0 >>>>> =A0 =A0 =A0 ret =3D grub_malloc (sizeof (*ret)); >>>>> >>>>> Now here's the tricky part, when i fix both problem, it actually when >>>>> you call this: (memdisk size is 19,180, just in case it matters). >>>>> >>>>> testspeed /memdisk >>>>> >>>>> So there must be a memory corruption somewhere. >>>> You can check for memory corruptions by calling grub_mm_check often >>>> enough in the code. >>> Hi, >>> >>> Thanks for the tip. But when I add a few grub_mm_check and printf here >>> and there, it doesn't halt any more. So this could be a memory >>> overflown issue or even compiler bug, very strange indeed. >> Hi, >> >> Well, actually it does halt with a larger file, so at least the >> behavior is predictable. > Could you try to allocate the buffer for receive/send EFI calls only > once per card? It will result in needless copying but would solve few > DMA issues if network driver is badly coded. Hi, Yeah, I have a patch that save the buffer for later use when there is no data, it can solve the unnecessary alloc/free loop. --=20 Best wishes Bean