buglwIP - A Lightweight TCP/IP stack - Bugs: bug #36273, Bug with MEMP_MEM_MALLOC = 0

 
 

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

bug #36273: Bug with MEMP_MEM_MALLOC = 0

Submitter:  dagos <dagos>
Submitted:  Mon 23 Apr 2012 10:04:24 AM UTC
   
 
Category:  pbufs Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Works For Me
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
lwIP version:  1.4.0

Mon 19 May 2014 08:19:30 PM UTC, comment #4: 

Can't reproduce, so I strongly vote for a threading issue in the port used.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 04 May 2012 11:49:22 AM UTC, comment #3: 

A quick look at your files didn't show any errors in lwIP handling, so I'd have to see if I can reproduce the bug with your files...

Simon Goldschmidt <goldsimon>
Group administrator
Fri 04 May 2012 10:38:50 AM UTC, comment #2: 

Configuration LWIP:
PILE_ADDR_IP=10.129.0.11
PILE_NETMASK=255.255.255.0
PILE_ADDR_MAC=00:00:5D:00:00:01

I have 3 threads (look at testeur_bug.c):
2 serveurs threads (1 UDP and 1 TCP)
1 main thread in which client connect to serveur this way:

100 loops:
  2 x TCP client (connect, send, recv, and déconnect) (CAS1)
  2 x UDP client (connect, send, recv, and déconnect) (CAS2)

At a certain time (which is random), there is a bug in pbuf (see below)

I have 2 serveurs threads so I call 'netconn_recv' in each threads (possible at the same time...). Is this wrong ?

I don't use Interrupts / Callbacks at all.


* CAS1 *
CAS1: Fin de la connexion!
CAS1: Connexion TCP acceptée par la pile LWIP sur le port 1100!
CAS1: TEST OK: Donnée TCP reçue coté pile LWIP sur port 1100: * DONNEE DE TEST *!
CAS1: TEST OK: Acquittement reçu: ACK!!

CAS1: Fin de la connexion!

* CAS2 *
CAS2: TEST OK: Donnée UDP reçue coté pile LWIP sur port 1100: E!  ====> BUG!!!
CAS2: TEST OK: Acquittement reçu: E!   ====> BUG!!!

and later:
Assertion "pbuf_free: p->ref > 0" failed at line 627 in SRC/lwip-1.4.0/src/core/pbuf.c




dagos <dagos>
Thu 03 May 2012 06:26:33 PM UTC, comment #1: 

I'm not totally getting what your problem is, but are you 100% sure you don't violate lwIP's threading requirements (i.e. only one thread may be active in lwIP at a time - which also means when using the tcpip_thread, your netif must not pass packets into lwIP from interrupt context unless using tcpip_input for that)?

Simon Goldschmidt <goldsimon>
Group administrator
Mon 23 Apr 2012 10:04:24 AM UTC, original submission:  

Hello,
With MEM_LIBC_MALLOC = 0, when doing multiples TCP connexions before UDP connexions,
UDP netconn_recv returns a pbuf at always the same address,
and data associated is wrong:

I have (UDP DATA FIELD, with WireShark):

          E..2..
................
.....c*** DONNEE
 DE TEST *

Instead of (UDP DATA FIELD, with WireShark):

          * DO
NNEE DE TEST *


Output with MEM_LIBC_MALLOC = 0:

* CAS1 (TCP) *
CAS1: Connexion TCP acceptée par la pile LWIP sur le port 1102!
CAS1: TEST OK: Donnée TCP reçue sur port 1102: * DONNEE DE TEST *!
CAS1: TEST OK: Acquittement reçu: ACK!!
CAS1: Fin de la connexion!

* CAS2 (TCP) *
CAS2: Connexion TCP acceptée par la machine UNIX sur le port 1202.
CAS2: TEST OK: Donnée TCP reçue sur port 1202: * DONNEE DE TEST *!
CAS2: TEST OK: Acquittement reçu: ACK!!
CAS2: Fin de la connexion!

* CAS3 (UDP) *
CAS3: TEST OK: Donnée UDP reçue sur port 1102: E!   ===> BUG
CAS3: TEST OK: Acquittement reçu: E!                ===> BUG (same pbuf, but another netconn_recv call)


* CAS4 (UDP) *
CAS4: TEST OK: Donnée UDP reçue sur port 1202: E!   ===> BUG (same pbuf, but another netconn_recv call)
CAS4: TEST OK: Acquittement reçu: E!                ===> BUG (same pbuf, but another netconn_recv call)


* CAS1 (TCP) *
CAS1: Connexion TCP acceptée par la pile LWIP sur le port 1102!
CAS1: TEST OK: Donnée TCP reçue sur port 1102: * DONNEE DE TEST *!   ==> pbuf is OK for netconn_recv TCP!
CAS1: TEST OK: Acquittement reçu: ACK!!
CAS1: Fin de la connexion!

etc...


Note that if I don't use TCP connexions (only CAS3 and CAS4), the problem is not present.
It's looks like the problem occurs when a TCP netconn is closed on a side when TCP netconn is receiving in the other size.

With MEM_LIBC_MALLOC = 1, no problem found.

Sorry for my english ;)

dagos <dagos>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #25780:  testeur_bug.c added by dagos (12KiB - text/x-c)
file #25781:  low_level.c added by dagos (16KiB - text/x-c)
file #25715:  lwipopts.h added by dagos (13KiB - text/x-chdr)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-05-19 goldsimon StatusNeed Info Works For Me
        Open/ClosedOpen Closed
    2012-05-04 goldsimon Assigned toNone goldsimon
    2012-05-04 dagos Attached File- Added testeur_bug.c, #25780
        Attached File- Added low_level.c, #25781
    2012-05-03 goldsimon StatusNone Need Info
    2012-04-23 dagos Attached File- Added lwipopts.h, #25715

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code