ODP: [lwip-devel] Memory (debugging) problem

[Małowidzki , Marek]

Ok, so I think I have found the problem (1.3.0).
 
memp_sizes is defined in memp.c as:
 
const u16_t memp_sizes[MEMP_MAX] = {

#define LWIP_MEMPOOL(name,num,size,desc) MEMP_ALIGN_SIZE(size),

#include "lwip/memp_std.h"

};

where

#define MEMP_ALIGN_SIZE(x) (LWIP_MEM_ALIGN_SIZE(x) + 
MEMP_SANITY_REGION_AFTER_ALIGNED)

so, the block size is increased by the sanity region length.

Now - in mem_malloc() (mem.c), the expression that looks for a sufficiently 
large block of memory is as follows:
 
if ((size + sizeof(struct mem_helper)) <= memp_sizes[poolnr]) {

however, memp_sizes have been increased; thus, the selected block may be too 
small and writing the whole allocated region will overwrite the guards.

I think that, due to code organization, which is quite complex, it is difficult 
for me to suggest a neat patch. For now, I have introduced another array, 

const u16_t memp_bare_sizes[MEMP_MAX] = { 

#define LWIP_MEMPOOL(name,num,size,desc) LWIP_MEMP_ALIGN_SIZE(size),

#include "lwip/memp_std.h"

};

and changed mem_malloc() to
 
if ((size + sizeof(struct mem_helper)) <= memp_bare_sizes[poolnr]) {
 
the problem seems to be solved.
 
Also, as I suggested previously, it seems that etharp_raw() should change 
PBUF_LINK to PBUF_RAW in the following line:
 
p = pbuf_alloc(PBUF_LINK, sizeof(struct etharp_hdr), PBUF_RAM);
 
since it creates the whole Ethernet frame at once, no additional space for an 
Ethernet header is necessary at the beginning.
 
Marek

________________________________

Od: address@hidden w imieniu Małowidzki, Marek
Wysłano: Cz 2009-03-26 09:10
Do: lwip-devel; lwip-devel
Temat: ODP: [lwip-devel] Memory (debugging) problem


> Could you file a bug report on savannah? Otherwise this is bound to go 
> unnoticed if not
> fixed (*if* it's a bug) right away.

> I think you are right on the PBUF_RAW, though. Are you using CVS HEAD or 1.3.0
> (or even an older version)? I remember wanting to change this in CVS HEAD but 
> I don't
> remember if I really did ;-)

Sorry, I forgot to mention, yes, we are using 1.3.0.
 
I try to have a one more look at this issue, maybe I will be able to suggest a 
patch.
 
Marek

<<winmail.dat>>