[Live-devel] patch for stackoverflow

[Ross Finlayson]

>The problem is that:
>1. MultiFramedRTPSource::doGetNextFrame1() is called
>2. in this method afterGetting(this); is called
>3. afterGetting(this) does a lot, but in the end it calls 
>continuePlaying() which again calls 
>MultiFramedRTPSource::doGetNextFrame()
>4. MultiFramedRTPSource::doGetNextFrame() again calls 
>MultiFramedRTPSource::doGetNextFrame1()
>which can lead to the stack overflow.

Erwin,

Under normal circumstances, that's not the case.  Step 2 directly 
follows step 1 only when there is previously read, but still unused, 
incoming RTP packet data awaiting to be processed.  In most 
circumstances, this chain of calls ends quickly, and the code's 
control flow returns to the event loop - so there's no stack overflow.

On looking at the code some more, however, I realize that there is 
one special situation that *may* cause a long chain of calls (and 
thus potentially a stack overflow, especially if you have a small 
stack).  If you are receiving a high-bitrate stream that has some 
packet loss, then it is possible - with the current code - to have a 
long chain of calls (when processing the queue of packets that 
arrived after a lost packet).

Until I fix this problem (in the next release), you can work around 
it by changing "fThresholdTime(100000)" on line 433 of 
"MultiFramedRTPSource" to "fThresholdTime(0)".  (Note that the 'fix' 
that you suggested is not correct, because it won't properly handle 
those RTP payload formats that include more than one frame in each 
RTP packet.)

>Another thing i noticed is that many pointers,buffers,variables are 
>not initialized correctly in the constructors.
>The library assumed that the compiler initializes all variables to 0

The library should not be assuming this.  Whenever it does not 
initialize a variable, this is because it does not expect the 
variable to be read before it is first assigned.  If, however, you 
find places where the library is (improperly) assuming that a 
variable is initialized to 0, then please let us know, so we can fix 
this.

>Perhaps it would be better to initialize all 
>variables,buffers,pointers in the constructors

As I noted above, for efficiency we sometimes do not initialize a 
variable in the constructor if we know that it will never be accessed 
prior to first being assigned.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/