[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mysterious memory corruption bug

From: Bean
Subject: Re: Mysterious memory corruption bug
Date: Wed, 2 May 2012 04:02:45 +0800

On Wed, May 2, 2012 at 3:56 AM, Vladimir 'φ-coder/phcoder' Serbinenko
<address@hidden> wrote:
> On 01.05.2012 21:52, Bean wrote:
>> On Wed, May 2, 2012 at 3:46 AM, Bean <address@hidden> wrote:
>>> On Wed, May 2, 2012 at 3:08 AM, Vladimir 'φ-coder/phcoder' Serbinenko
>>> <address@hidden> 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
>>>>>       rsm = grub_malloc (sizeof (*rsm));
>>>>> Another problem is at ip.c:594:
>>>>>   return handle_dgram (ret, card, src_hwaddress,
>>>>>                              hwaddress, proto, &source, &dest,
>>>>>                              ttl);
>>>>> 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 separately
>>>>> so that it's not free using , you can see it from printmem at ip.c:580
>>>>>       ret = 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.


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.

Best wishes

reply via email to

[Prev in Thread] Current Thread [Next in Thread]