buglwIP - A Lightweight TCP/IP stack - Bugs: bug #37158, MEM_USE_POOLS==1: LWIP_ASSERT...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #37158: MEM_USE_POOLS==1: LWIP_ASSERT (rmem == LWIP_MEM_ALIGN(rmem)) fails

Submitted by:  Artem Pisarenko <jblackarty>
Submitted on:  Tue 21 Aug 2012 01:53:56 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Duplicate
Privacy: PublicAssigned to: Simon Goldschmidt <goldsimon>
Open/Closed: ClosedPlanned Release: None
lwIP version: 1.4.0

Wed 22 Aug 2012 07:04:47 PM UTC, comment #3:

This is a duplicate to bug #33545, already fixed shortly after 1.4.0 was released -> already fixed for 1.4.1.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Wed 22 Aug 2012 04:45:54 AM UTC, comment #2:

Yes, it's line 134 in my sources too. Seems like debugger interpret sources or places breakpoints in some tricky way.

I'm writing my own port from scratch for STM32F2x7 MCU with ARM Cortex-M3 processor. This processor supports unaligned accesses in simple terms (although ARMv7-M Architecture Reference Manual restricts unaligned access in some cases and I'm not sure how gcc compiler workaround these ones).

Anyway it works ok as I said before (I've just configured to debug output asserts). There are no need to remove asserts. 2nd assert doesn't fail, it's ok. But I still didn't tested my port heavily. I've just run standard tcpecho example from contribs until now.

Also I forget to say that I use non-original lwip sources. I modified them a little to temporary solve bug #37148:
May be my solution wasn't correct and triggered this issue. But I cannot check without this fix because my lwip port cannot even start without it.

Artem Pisarenko <jblackarty>
Tue 21 Aug 2012 02:39:39 PM UTC, comment #1:

[Updating the summary to reflect MEM_USE_POOLS==1]

First: the LWIP_ASSERT line you quoted is line 134 in my 1.4.0 sources, not line 137 as the stack trace says.

As alignment is highliy port-dependent, could you tell us what hardware/lwIP-port you are using and what's the native alignment requirement of that hardware?

It seems like your bug report is true, though: for MEM_USE_POOLS==1, mem_malloc() gets an aligned 'element' pointer from memp_malloc() and then increases 'element'. The resulting pointer might not be aligned any more, as the struct memp_malloc_helper only contains one memp_t, which will be an u8_t.

Could you remove the assert from mem.c:134 and see if it works? Especially the 2nd next assert which checks that 'hmem' is alingned should not fire. If so, I'd just remove line 134...

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Tue 21 Aug 2012 01:53:56 PM UTC, original submission:

lwip assertion fails at line:
in function mem_free() at mem.c.

It happens each time on tcp activity. But everything works ok (looks like that).

rmem = 0x6400a669
Call stack:
Initial data:
msg->msg.inp.p = 0x20009cb4
Ethernet driver allocates pbufs for incoming frames in this way:

lwipopts.h:
lwippools.h:

Artem Pisarenko <jblackarty>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by goldsimon (Posted a comment)
  • -unavailable- added by jblackarty (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 22 Aug 2012 07:04:47 PM UTCgoldsimonStatusNeed Info=>Duplicate
      Open/ClosedOpen=>Closed
    Tue 21 Aug 2012 02:39:39 PM UTCgoldsimonStatusNone=>Need Info
      Assigned toNone=>goldsimon
      SummaryLWIP_ASSERT (rmem == LWIP_MEM_ALIGN(rmem)) fails=>MEM_USE_POOLS==1: LWIP_ASSERT (rmem == LWIP_MEM_ALIGN(rmem)) fails

    Back to the top


    Powered by Savane 3.1-cleanup1