[Live-devel] Potential Issues in ReorderingPacketBuffer Class Implementation

Ross Finlayson finlayson at live555.com
Wed Sep 17 14:17:20 PDT 2008


>The first issue is related to :  delete fHeadPacket when reset() method of
>ReorderingPacketBuffer is called. The fHeadPacket pointer can be NULL if it
>is calling in the context of ~ReorderingPacketBuffer() when the medium
>source is closed. I know it legal on C++ but it is confusing for someone
>trying to understand the code.

There are many places in the code where delete might be called on a 
pointer that happens to be NULL.  As you noted, this is legal (and it 
simplifies code considerably).

>  I have not thoroughly checked but I also
>worry that in some cases when the medium is closed that fHeadPacket and
>fSavedPacket are identical and non null causing a double delete.

No, that won't happen, because if "fHeadPacket" and "fSavedPacket" 
are identical (which is actually the common case), then 
"fSavedPacketFree" will be False, so the call to "delete 
fSavedPacket;" won't happen.

>The second issue is related to the allocation of BufferedPacket. If the
>medium source is closed while many buffered packet are chained together
>because of a reordering issue at this moment then I believe the
>BufferedPacket allocated by the method getFreePacket won't be freed and will
>cause memory leaks.

No, each of the "BufferedPacket"s in the chain will be deleted as a 
result of the call to "delete fHeadPacket;", because the 
"BufferedPacket" destructor includes the line "delete fNextPacket;".


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>



More information about the live-devel mailing list