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

Submitter:  Woody Wu <narke>
Submitted:  Thu 16 Feb 2012 03:17:03 AM UTC
   
 
Category:  PPP Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned 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>
Group administrator
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>
Group 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>
Group administrator
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>
Group administrator
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>

 

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

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2014-09-02 goldsimon StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2013-01-14 goldsimon CategoryNone PPP
    2012-02-16 goldsimon StatusNeed Info In Progress
    2012-02-16 goldsimon StatusNone Need Info
        Assigned toNone goldsimon

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code