On 01.05.2012 21:52, Bean wrote:
> On Wed, May 2, 2012 at 3:46 AM, Bean <bean123ch@gmail.com> wrote:
>> On Wed, May 2, 2012 at 3:08 AM, Vladimir 'φ-coder/phcoder' Serbinenko
>> <phcoder@gmail.com> 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.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko