buglwIP - A Lightweight TCP/IP stack - Bugs: bug #35541, PPP Memory Leak

 
 

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

bug #35541: PPP Memory Leak

Submitted by:  Woody Wu <narke>
Submitted on:  Thu 16 Feb 2012 03:17:03 AM UTC  
 
Category: PPPSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Simon Goldschmidt <goldsimon>
Open/Closed: ClosedPlanned Release: None
lwIP version: 1.4.0

Tue 02 Sep 2014 06:12:11 PM UTC, comment #4:

This should be fixed by now after switching to ppp-new

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Fri 02 Mar 2012 05:11:47 PM UTC, comment #3:

How about adding pppFreeCurrentInputPacket(&pc->rx); in pppLinkTerminated(), after pc->openFlag = 0;

Ivan Delamer <idelamer>
Project Member
Thu 16 Feb 2012 11:57:34 AM UTC, comment #2:

I've pushed a fix for the memory leak in pppOverSerialOpen(): if a pbuf is left over, it is freed. However, this doesn't free any pbufs between HUP and reopen.

I'll add this fix to 1.4.1 since it's low risk, but I'll leave this one open to discuss the free-on-HUP issue.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Thu 16 Feb 2012 08:45:44 AM UTC, comment #1:

I suggest 2 fixes for this:
- in pppOverSerialOpen(), call pbuf_free(pc->rx.inHead) if != NULL before zeroing 'pc' using memset()
- always call pppRecvWakeup() and reset the pc->rx state in the function before calling sio_read_abort()

While the first should be enough to fix the leak, the latter is nice to have.

The latter change would require that sio_recv()/sio_read() do not return any RX bytes if they were aborted (or they would lead to allocating a pbuf again).

As I'm not in a position to test this (I don't have a working PPP setup), can you test this from git if I make the changes? If you can test it quickly, I'd be tempted to add this to 1.4.1...

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Thu 16 Feb 2012 03:17:03 AM UTC, original submission:

I found the bug in practice. Before I call pppSigHUP, there might be
some un-concluded frame accumulated in ppp, thus a pbuf might be
allocated but not yet freed. This un-concluded frame might be an
incorrect PPP frame. After I call the pppSigHUP, the allocated pbuf
stay in ppp as allocated state. The detail you can refer to the
pppInProc() function. Then next time, when I have to reopen the ppp,
I can only call the pppOverSerialOpen() function, but this function
will reset ppp receive parser state variables, that results in the
allocated pbuf will never get chance to be freed.

Currently, my workaround solution is to feed the ppp with a 0x7e character before I can pppSigHUP. This extra ppp ending flag cause the pppInProc() state machine check the un-concluded frame and release it.

Woody Wu <narke>

 

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

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 02 Sep 2014 06:12:11 PM UTCgoldsimonStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Mon 14 Jan 2013 09:06:00 PM UTCgoldsimonCategoryNone=>PPP
    Thu 16 Feb 2012 11:57:34 AM UTCgoldsimonStatusNeed Info=>In Progress
    Thu 16 Feb 2012 08:45:44 AM UTCgoldsimonStatusNone=>Need Info
      Assigned toNone=>goldsimon

    Back to the top


    Powered by Savane 3.1-cleanup1