Re: Mysterious memory corruption bug

[Bean]

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.

-- 
Best wishes
Bean