Well, from what I can tell this bug has existed for the entire history of mem.c in CVS.
The bug seems to be a result of line 256, where the size of the 'mem' struct is counted twice. Instead of: mem->next - (ptr + SIZEOF_STRUCT_MEM) >= size + SIZEOF_STRUCT_MEM) It should read: mem->next - ptr >= size + SIZEOF_STRUCT_MEM) That isn't the only fix required however. The code that updates mem2 assumes that mem2 is in some region of memory that isn't currently allocated. However, with the fix above (and the test case I provided earlier) mem2 will point to a valid, already existing 'mem' struct and so it shouldn't be updated. To solve this problem after figuring out the value of ptr2 there should be a check to see if mem->next points to ptr2, if it does then mem2 is a valid struct and should be updated. If it doesn't point to ptr2 then it should be safe to create a new 'mem' struct at that location. Note that this solution ignores the problem of what would happen if ptr2 actually pointed half-way into the existing 'mem' struct. On 10/4/06, Christiaan Simons <[EMAIL PROTECTED]> wrote:
Hi Tom, > I've run across what I believe to be a bug in mem_malloc. Yikes. I'm currently working on some SNMP agent stuff that heavily uses mem_malloc()... > I have an idea why this is failing (and a possible method to fix it), > but I wanted to make sure this wasn't already known and expected. I wasn't aware of this. mem_malloc() did seem to work ok for me, but I may have missed this odd corner. Can you please share your thoughts with us? Christiaan Simons Hardware Designer Axon Digital Design http://www.axon.tv _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
