[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