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

Submitted by:  dagos <dagos>
Submitted on:  Mon 23 Apr 2012 10:04:24 AM UTC  
 
Category: pbufsSeverity: 3 - Normal
Item Group: Faulty BehaviourStatus: Works For Me
Privacy: PublicAssigned to: Simon Goldschmidt <goldsimon>
Open/Closed: ClosedPlanned 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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>

 

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
  • -unavailable- added by goldsimon (Posted a comment)
  • -unavailable- added by dagos (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 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 19 May 2014 08:19:30 PM UTCgoldsimonStatusNeed Info=>Works For Me
      Open/ClosedOpen=>Closed
    Fri 04 May 2012 11:49:22 AM UTCgoldsimonAssigned toNone=>goldsimon
    Fri 04 May 2012 10:30:53 AM UTCdagosAttached File-=>Added testeur_bug.c, #25780
      Attached File-=>Added low_level.c, #25781
    Thu 03 May 2012 06:26:33 PM UTCgoldsimonStatusNone=>Need Info
    Mon 23 Apr 2012 10:04:24 AM UTCdagosAttached File-=>Added lwipopts.h, #25715

    Back to the top


    Powered by Savane 3.1-cleanup1